VulWall Team February 18, 2026 5 min read

Your Domain Has No Email Sender Verification — Anyone Can Impersonate You

Your domain is missing a basic email safety record called SPF. Without it, there is no mechanism in place to tell other email services which servers are allowed to send email on your behalf. Think of it like a building without a guest list — anyone can show up claiming to be from your company.

OWASP A05 Effort: trivial Exploitable
spf email dns spoofing phishing email-authentication misconfiguration

Business Impact And Actions

medium urgency

Business Impact

Without this record, bad actors can send emails that appear to come from your domain — targeting your customers, partners, or staff. This can damage your brand reputation, erode customer trust, and may cause your own legitimate emails to land in spam folders. If you send marketing or transactional emails, missing SPF can also hurt your email deliverability and flag you in compliance reviews.

What To Do

  1. Ask your developer or IT person to add an SPF record to your domain's DNS settings — this is typically a 30-minute task.
  2. Make sure they include all services that send email on your behalf (e.g. Google Workspace, Mailchimp, SendGrid) in the record.
  3. Once added, ask them to verify it using a free tool like MXToolbox (mxtoolbox.com/spf.aspx) to confirm it's set up correctly.
  4. Ask your developer whether DKIM and DMARC are also configured — SPF works best as part of a trio of email protections.

Missing SPF TXT Record — Domain Open to Email Spoofing

medium severity

Vulnerability Explanation

The domain has no SPF (Sender Policy Framework) TXT record published in DNS. SPF allows receiving mail servers to verify that inbound email claiming to originate from this domain was sent from an authorized mail server. Without an SPF record, there is no published policy for receiving servers to check, meaning any server on the internet can send email with a From or envelope-from address belonging to this domain. Receiving servers that do check SPF will see a 'none' result (not a 'fail'), which most treat permissively — delivering the message or applying only soft filtering. The absence of SPF also undermines any DMARC policy, since DMARC alignment requires either SPF or DKIM to pass.

Root Cause

The domain was registered or configured without publishing an SPF TXT record in DNS. The SMTP protocol has no built-in sender authentication, so SPF must be explicitly opted into by domain owners via a DNS TXT record. This is a configuration omission, not a software vulnerability.

Technical Impact

An attacker can send spoofed emails that appear to originate from this domain. Depending on the recipient's mail server configuration and the absence of DMARC, these emails may be delivered directly to inboxes. This enables phishing attacks against customers, partners, or employees; business email compromise (BEC) scenarios; and reputational damage to the domain. Additionally, the domain's own legitimate outbound email may be marked as spam or rejected by strict receiving servers that require SPF.

Severity Justification

Email spoofing is realistically exploitable with no authentication required — any actor can attempt it using freely available tools. However, real-world impact depends on the recipient's mail server filtering, the absence of DMARC, and whether the domain is a recognizable brand. Rated medium (not high) because modern spam filters and DMARC adoption reduce the deliverability of spoofed mail in many environments, and the fix is straightforward.

Affected Components

  • Domain DNS configuration — all versions (no SPF TXT record present)

Remediation Steps

  1. Identify all services that send email on behalf of this domain (e.g. Google Workspace, Microsoft 365, SendGrid, Mailchimp, your web server). Each must be included in the SPF record.
  2. Construct an SPF TXT record using the syntax: `v=spf1 [include/ip mechanisms] -all`. Use `include:` for third-party providers and `ip4:`/`ip6:` for specific sending IPs. End with `-all` (hard fail) to reject unauthorized senders. Example for Google Workspace: `v=spf1 include:_spf.google.com -all`. Example for Microsoft 365: `v=spf1 include:spf.protection.outlook.com -all`. For a domain that sends no email at all: `v=spf1 -all`.
  3. Log in to your DNS provider (e.g. Cloudflare, Route 53, GoDaddy, Namecheap) and add a new TXT record at the root of the domain (`@`) with the SPF value. Do not create more than one SPF TXT record per domain — combine all mechanisms into a single record.
  4. Validate the record syntax before and after publishing using MXToolbox (https://mxtoolbox.com/spf.aspx) or the dmarcian SPF Surveyor (https://dmarcian.com/spf-survey/). Ensure the record does not exceed 10 DNS lookup mechanisms.
  5. Allow up to 48 hours for DNS propagation, then re-run the scanner or use a lookup tool to confirm the record is live.
  6. Plan to also implement DKIM and DMARC (starting with `p=none` for monitoring) — SPF alone is insufficient to prevent spoofed emails from reaching inboxes if DMARC is absent.

Verification Steps

  1. Run: `dig TXT yourdomain.com | grep spf` — you should see a TXT record starting with `v=spf1`.
  2. Alternatively: `nslookup -type=TXT yourdomain.com` and look for the SPF record in the output.
  3. Use MXToolbox SPF checker at https://mxtoolbox.com/spf.aspx and confirm the result shows 'SPF Record Found' with no syntax errors.
  4. Send a test email to a Gmail or Outlook address and check the message headers for `Received-SPF: pass`.

Code Examples (dns)

Vulnerable
; No SPF TXT record exists for the domain
; (dig TXT example.com returns no SPF result)
Fixed
; For a domain using Google Workspace:
example.com. IN TXT "v=spf1 include:_spf.google.com -all"

; For a domain using Microsoft 365:
example.com. IN TXT "v=spf1 include:spf.protection.outlook.com -all"

; For a domain using multiple providers (Google + SendGrid):
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

; For a parked / non-sending domain:
example.com. IN TXT "v=spf1 -all"

Best Practices

  • Always use `-all` (hard fail) rather than `~all` (soft fail) once you have confirmed all legitimate senders are included — soft fail is treated permissively by many mail servers.
  • Keep the number of `include:` mechanisms to 10 or fewer to avoid the SPF DNS lookup limit, which causes SPF to return a PermError.
  • Publish a defensive `v=spf1 -all` record on all parked or non-sending domains to prevent them from being abused for spoofing.
  • Pair SPF with DKIM and a DMARC policy of at least `p=quarantine` for complete protection — SPF alone can be bypassed if DMARC is not enforcing.

References

Found this in your infrastructure?

VulWall scans for this and dozens of other issues automatically.

Scan Your Domain Free
Back to Knowledge Base