Why Email Authentication Matters: SPF, DKIM, and DMARC Explained
Introduction
You can send an email claiming to be from any domain on the internet. Right now. No hacking required. No password to crack. The SMTP protocol — the 40-year-old foundation of email — was designed in an era when the internet was a research network of mutually trusting institutions, and it has no built-in mechanism to verify that the sender is who they claim to be.
This is why phishing works. An attacker sends an email from [email protected], [email protected], or [email protected], and the recipient — seeing a legitimate-looking sender address — opens the attachment, clicks the link, or wires the money. The attacker didn't compromise your email server. They didn't steal your credentials. They simply connected to any SMTP server and wrote your domain in the From field.
SPF, DKIM, and DMARC are three complementary standards designed to close this gap. Together, they let you tell the world's mail servers: "Here is who is authorised to send email from my domain. Here is how you can verify that an email genuinely came from them. And here is what you should do if authentication fails."
This article explains how email spoofing works, what each authentication standard does, how to set them up, and how ScanSentinel checks your configuration so you can be sure it's working.
How Email Spoofing Works
To understand why SPF, DKIM, and DMARC exist, you need to understand how trivially easy email spoofing is without them.
When an email is sent, the SMTP protocol separates the "envelope" from the "message." The envelope contains the MAIL FROM address (also called the return-path or bounce address) — this is the address where bounce notifications are delivered. The message contains the From header — this is the address the recipient sees in their email client.
An attacker can set the From header to any value they want. Most SMTP servers don't validate whether the sender is authorised to use that domain. The email passes through, the recipient sees From: [email protected], and they act on it.
This is not a vulnerability that needs patching. It's how SMTP was designed. The protocol treats the From address the way a physical letter treats the return address on the envelope — as information provided by the sender, not as a verified identity.
SPF, DKIM, and DMARC add the verification layer that SMTP never had:
SPF verifies that the sending server is authorised to send email for the domain (envelope-level).
DKIM cryptographically signs the email so the recipient can verify it hasn't been tampered with and genuinely originated from the claimed domain (message-level).
DMARC tells the recipient what to do when SPF or DKIM checks fail, and provides reporting so you can see who is attempting to send email from your domain (policy and reporting layer).
SPF: Authorising Senders
What SPF Does
SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and hostnames authorised to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from @yourdomain.com, it checks your SPF record. If the sending server's IP address is in your list, the SPF check passes. If it isn't, it fails.
An SPF record looks like this:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
Let's break that down:
v=spf1 — This is an SPF record, version 1.
include:_spf.google.com — Also authorise any IP addresses listed in Google's SPF record (if you use Google Workspace).
include:spf.protection.outlook.com — Also authorise IPs from Microsoft's SPF record (if you use Microsoft 365).
-all — Explicitly fail any email from IP addresses not listed above. This is a "hard fail."
SPF Qualifiers
The last part of the SPF record — the all mechanism — is critical and often misunderstood:
`-all`: Hard fail. Reject email from unauthorised sources.
`~all`: Soft fail. Accept the email but mark it as suspicious.
`?all`: Neutral. Do nothing.
`+all`: Pass. Allow everything.
Many domains use ~all indefinitely, which means spoofed emails may still be delivered (marked as suspicious, but delivered). The goal should be to move to -all once you've confirmed your legitimate email services are all covered by your SPF record.
Limitations of SPF
SPF has two significant limitations:
It checks the envelope sender, not the From header. An attacker can use a domain they control as the envelope sender (passing SPF) while setting the From header to your domain. The recipient sees your domain; SPF checked a different domain.
SPF breaks when email is forwarded. If a recipient forwards an email from your domain to another address, the forwarding server's IP won't be in your SPF record, and the SPF check will fail at the final destination.
Both limitations are addressed by combining SPF with DKIM and DMARC.
DKIM: Signing Your Emails
What DKIM Does
DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing email. The signature is created using a private key held by your email provider. The corresponding public key is published in a DNS TXT record at a specific subdomain. When a receiving mail server gets a signed email, it fetches the public key from your DNS and verifies the signature.
A DKIM signature header looks something like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com;s=google; h=from:to:subject:date; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;b=KbLQcUwSi6PhBzJwq5IQ2jFqR3T0m1pCFnK9gJL8XoeC0m4R7tVsBqY3n1hDdE5w
The signature covers both the message body and selected headers (the h= tag lists which ones). If the message is modified in transit — even a single character — the signature won't verify.
Where DKIM Fits
Unlike SPF, DKIM survives forwarding. The signature is part of the email itself, so forwarding servers can't strip or invalidate it (unless they modify the signed headers or body). This makes DKIM particularly important for domains that send email to recipients who forward their mail — which is most domains.
A DKIM record lives at a specific subdomain: [selector]._domainkey.yourdomain.com. The selector is an arbitrary label that identifies which key pair to use. Most email providers (Google, Microsoft, SendGrid, Mailchimp, etc.) assign a specific selector and provide the DNS record values when you enable DKIM.
What ScanSentinel Checks
Because the DKIM selector can be anything, an external scanner can't know for certain which selector you're using. ScanSentinel searches for DKIM records across 10 common selectors: default, google, dkim, mail, selector1, selector2, s1, s2, zoho, and protonmail. If any of these returns a valid DKIM record, we report DKIM as present.
If your DKIM selector isn't in this list, the scanner won't find it. This is a limitation of external DNS scanning — the scanner has no way to know which arbitrary selector you chose. For this reason, even if ScanSentinel reports DKIM as missing, you may still have DKIM configured. Check with your email provider to confirm.
DMARC: Tying It All Together
What DMARC Does
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy framework that connects SPF and DKIM. A DMARC record tells receiving mail servers three things:
How to authenticate email from my domain. At least one of SPF or DKIM must pass, and the domain used by the passing mechanism must align with the domain in the From header.
What to do when authentication fails. Quarantine the message (send it to spam), reject it (don't deliver it at all), or do nothing (deliver normally but send me a report).
Where to send reports. DMARC can generate aggregate reports (daily summaries of authentication results) and forensic reports (detailed information about specific failures).
A DMARC record looks like this:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100;
Breaking it down:
v=DMARC1 — DMARC version 1.
p=quarantine — Policy: quarantine emails that fail authentication (send them to spam).
rua=mailto:[email protected] — Send aggregate reports to this address.
ruf=mailto:[email protected] — Send forensic reports to this address (optional, and many providers don't generate them for privacy reasons).
pct=100 — Apply this policy to 100% of failing emails.
DMARC Policies
The p= tag defines your enforcement level:
`p=none`: Deliver normally. Only send reports.
`p=quarantine`: Send failing emails to the spam folder.
`p=reject`: Reject failing emails at the SMTP level. Don't deliver them.
DMARC and Alignment
DMARC introduces the concept of "alignment" — the domain that passes SPF or DKIM must match the domain in the From header.
For SPF, this means the MAIL FROM domain (envelope) must align with the From header domain. This prevents the attack where an attacker uses their own domain as the envelope sender (passing SPF) while spoofing your domain in the From header.
For DKIM, this means the d= tag in the DKIM signature must align with the From header domain. A DKIM signature from d=mailchimp.com doesn't authenticate email from d=yourdomain.com.
The Ideal Configuration
A domain that is fully secured with email authentication has:
An SPF record with -all (hard fail)
A DKIM record configured and signing all outgoing email
A DMARC record with p=quarantine or p=reject
With this configuration, an attacker cannot spoof email from your domain — or at least, the spoofed emails will be reliably rejected or quarantined by all major email providers.
Impact on Email Deliverability
Email authentication is no longer just about security. Major email providers now use authentication results as a primary factor in deliverability decisions.
In February 2024, Google (Gmail) and Yahoo (Yahoo Mail) began requiring bulk senders — anyone sending more than 5,000 emails per day to their platforms — to have DMARC configured. Google also requires that the DMARC policy be set to at least p=none, and recommends setting p=quarantine or p=reject.
Microsoft has signalled similar requirements. Apple's Mail Privacy Protection changes don't directly mandate DMARC, but the overall industry direction is clear: domains without proper email authentication will see their messages routed to spam or rejected outright.
If your domain sends any automated email — transactional notifications, password resets, invoices, marketing campaigns, newsletters — missing SPF, DKIM, or DMARC isn't just a security gap. It's a deliverability problem that directly affects your business operations.
For domains that don't send email, the recommendation is even stronger: set a DMARC record with p=reject. If your domain never sends email, no legitimate email should fail DMARC, and p=reject tells the world to discard anything that claims otherwise.
Setup Guides
Setting Up SPF
Identify your email senders. List every service that sends email using your domain: your email provider (Google Workspace, Microsoft 365, etc.), your transactional email service (SendGrid, Postmark, SES, etc.), your marketing platform (Mailchimp, HubSpot, etc.), and any other tools (support desk, CRM, billing system).
Collect their SPF include mechanisms. Each provider documents their SPF configuration. For example, Google Workspace uses include:_spf.google.com. Microsoft 365 uses include:spf.protection.outlook.com. Add each as an include: directive.
Create your SPF record. Combine the includes into a single TXT record at your domain root. For a domain using Google Workspace and SendGrid, the record would be:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Important: You can only have one SPF record per domain. If you already have one, edit it. Multiple SPF records cause authentication failures.
Start with ~all and monitor. Use soft fail initially. Monitor your email delivery and check for legitimate email sources you might have missed. Add them as additional include: directives.
Move to -all. Once you're confident all legitimate senders are covered, change the qualifier to -all for hard fail. This tells receiving servers to reject unauthorised email.
Keep the record under 10 DNS lookups. SPF has a hard limit of 10 DNS lookups per evaluation (includes, MX lookups, etc.). If you use many email services, consider using a subdomain for some of them or using a service that flattens SPF records.
Setting Up DKIM
DKIM setup depends on your email provider. The general process:
Enable DKIM in your email provider's admin console. For Google Workspace, it's under Apps > Google Workspace > Gmail > Authenticate Email. For Microsoft 365, it's under Exchange Admin Center > Protection > DKIM.
Copy the DNS record values provided. You'll typically get a hostname (like google._domainkey.yourdomain.com) and a TXT record value containing the public key.
Add the DNS records. Create TXT records for each selector your provider gives you. This is usually a one-time setup.
Verify. Use your provider's verification tool to confirm DKIM signing is active. Most providers show a green checkmark or "Authenticating" status once DKIM is correctly configured.
Repeat for each sending service. Each service that sends email on your behalf should have its own DKIM selector and key pair.
Setting Up DMARC
Start with monitoring only. Create a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100;
This enables DMARC but takes no action on failures — you'll only receive reports.
Collect reports for at least one to two weeks. Use a DMARC report analyser (several free ones exist, including Postmark's and dmarcian's) to understand what email is being sent from your domain and whether it's passing or failing authentication.
Fix authentication failures. If legitimate email is failing DMARC, adjust your SPF and DKIM configuration until all legitimate sources pass.
Tighten to quarantine. Once all legitimate email passes, update your policy:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100;
Move to reject (if appropriate). For domains that don't send email, or for sending domains after an extended period of monitoring:
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100;
Note: p=reject is the strongest protection but comes with risk — if you misconfigure SPF or DKIM and legitimate email fails authentication, it will be rejected. Business domains that rely on email delivery should carefully weigh the trade-off.
How ScanSentinel Validates Email Security
ScanSentinel's DNS security scanner automatically checks your email authentication configuration as part of every domain scan. Here's exactly what it does:
Detects whether your domain handles email. The scanner first resolves MX records for your domain. If no MX records are found, the scanner reports "no email" and skips further email checks — there's no point checking authentication for a domain that doesn't send or receive email.
Checks for SPF. Resolves TXT records at the domain root and looks for one starting with v=spf1. Reports whether SPF is present, shows the full record, and analyses the qualifier. It flags soft fail and neutral policies as warnings.
Searches for DKIM. Queries 10 common DKIM selectors — default, google, dkim, mail, selector1, selector2, s1, s2, zoho, and protonmail — at [selector]._domainkey.yourdomain.com. Reports whether a valid DKIM record (starting with v=DKIM1) was found at any selector.
Checks for DMARC. Resolves TXT records at _dmarc.yourdomain.com and looks for one starting with v=DMARC1. Extracts and reports the DMARC policy level (none, quarantine, or reject).
Reports findings. Each check produces a clear pass/fail result. The results are integrated into your domain's overall security score and appear in your dashboard, reports, and alerts.
Email security scanning is available on the Business plan, and DNS-only checks (SPF, DKIM, DMARC presence) are available on Pro and above.
Actionable Recommendations
Check your email authentication status right now. Use a free DNS lookup tool or ScanSentinel's scanner to check whether your domain has SPF, DKIM, and DMARC records. You might be surprised — many domains have none.
If your domain doesn't send email, set a reject policy. Add a DMARC record with p=reject and an SPF record with -all and no includes:
v=spf1 -all
v=DMARC1; p=reject; pct=100;
This tells the world: nobody should be sending email from this domain. Reject anything that claims otherwise.
If your domain does send email, implement SPF first. SPF is the easiest to set up and provides immediate protection against some spoofing attempts. Use ~all initially, monitor your configuration, then move to -all.
Enable DKIM with your email providers. This is usually a few clicks in an admin console and a DNS record. DKIM survives forwarding and provides cryptographic proof of origin — it's worth the effort.
Deploy DMARC with p=none as a starting point. Collect reports for at least two weeks. You'll learn which services are sending email from your domain — sometimes it's more than you expected. Fix authentication for all legitimate sources, then tighten the policy.
Monitor continuously. Email systems change. You add a new marketing platform, switch email providers, or reconfigure your DNS. Any of these can break your email authentication. Regular automated checks catch these changes before they affect your security or deliverability.