Email providers reject mail when authentication fails. Mailbox providers check three standards before accepting a message: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance). Missing or misconfigured records send your campaigns to spam or bounce entirely.
This post covers what each standard does, how to implement them, and how to diagnose when they break. Unlike a full deliverability audit, this focuses only on authentication setup and validation.
Why Email Authentication Matters
Mailbox providers (Gmail, Outlook, Yahoo) use authentication records to verify that you own the domain you claim to send from. Without these records, they treat your mail as suspicious. SPF, DKIM, and DMARC are the three signals they check in order.
If any one is missing or wrong, deliverability suffers. Gmail now requires DMARC alignment for senders pushing high volume. Yahoo and AOL enforce stricter checks. Misconfiguration is the most common reason campaigns land in spam or get rejected outright.
SPF: Authorize Servers to Send on Your Domain
SPF is a DNS record that lists which mail servers are allowed to send from your domain. When Gmail receives an email claiming to be from your domain, it checks the SPF record to see if the sending server is on the approved list.
SPF record structure: An SPF record is a single TXT record in your domain's DNS. It contains a list of IP addresses or domains authorized to send mail. A basic SPF record looks like this:
v=spf1 include:sendgrid.net include:mailchimp.com ~all
The v=spf1 tag declares the SPF version. The include: directives add third-party mail providers. The ~all at the end is a softfail: it says "if the sending server is not in this list, treat it as suspicious but still deliver." A hardfail (-all) rejects mail from unlisted servers entirely.
Add one include: line for each mail service you use (email platform, CRM, transactional mail service). Check your provider's documentation for the exact domain to include. Common examples:
- Mailchimp:
include:mailchimp.com - SendGrid:
include:sendgrid.net - HubSpot:
include:hubspot.com - Amazon SES:
include:amazonses.com
If you send from multiple providers, stack the includes. Do not list raw IP addresses unless you control the server directly.
Common SPF mistake: Adding too many includes. DNS limits SPF records to 10 includes. If you exceed this, SPF fails silently, and mail gets rejected. If you use more than 10 providers, consolidate or use a macro to reduce the count. Ask your mail provider if they support SPF flattening (a workaround that converts includes to IP addresses).
How to publish: Log into your domain registrar or DNS hosting service. Find the DNS settings for your domain. Add a new TXT record with the name @ or your domain root, and paste your SPF record. Save and wait 24 hours for propagation.
DKIM: Sign Messages Cryptographically
DKIM adds a cryptographic signature to each email. Mailbox providers use this signature to confirm that the message was sent by someone who controls your domain and has not been altered in transit.
Unlike SPF (which checks the sending server), DKIM signs the actual message content. This makes it harder to spoof because an attacker would need your private key to forge a valid signature.
How DKIM works: Your mail provider generates a public/private key pair. The public key goes into a DNS TXT record. When an email is sent, the provider signs it with the private key. Mailbox providers retrieve the public key from DNS and verify the signature. If the signature is valid, the message passes DKIM.
Most email platforms handle DKIM automatically. You do not generate the keys yourself. Instead, your provider gives you a DNS record to publish. The record is named with a selector (often default or selector1) and contains the public key.
A DKIM record looks like this:
default._domainkey.yourdomain.com TXT v=DKIM1; k=rsa; p=MIGfMA0GCSq...
The selector is the part before ._domainkey. Different providers use different selectors. Check your platform's setup guide for the exact record name and value.
Common DKIM mistake: Publishing the record with the wrong selector. If your provider says to use selector1 but you publish it under default, DKIM fails. Double-check the selector name in your provider's documentation before publishing.
Another mistake: Copying only part of the public key. DKIM keys are long (often 1,024 or 2,048 bits). If you paste only the first half, the record is invalid. Copy the entire key value, including the trailing semicolon.
How to publish: Log into your DNS provider. Add a new TXT record with the name your mail provider specifies (e.g., default._domainkey.yourdomain.com). Paste the full public key value. Save and wait 24 hours.
DMARC: Enforce Authentication and Set Policy
DMARC is a policy record that tells mailbox providers what to do if SPF or DKIM fails. It also provides reporting: you receive daily summaries of which messages passed or failed authentication.
DMARC requires that at least one of SPF or DKIM passes, and that the domain in the message aligns with the authenticated domain. For example, if an email claims to be from you@yourdomain.com, the SPF or DKIM check must pass for yourdomain.com.
DMARC record structure: A DMARC record is a TXT record published at _dmarc.yourdomain.com. A basic DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
The v=DMARC1 tag declares the version. The p= tag sets the policy:
p=none: Do nothing if DMARC fails. Mailbox providers will still deliver the mail and send you reports.p=quarantine: Send failing mail to spam if DMARC fails.p=reject: Bounce failing mail entirely if DMARC fails.
Start with p=none while you test. This lets you monitor failures without blocking legitimate mail. Once you confirm that all your mail passes DMARC, move to p=quarantine or p=reject.
The rua= tag specifies where to send aggregate reports. Use an email address you monitor. Mailbox providers send these reports daily in XML format. They show you how many messages passed or failed each check.
Full DMARC example with alignment:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1
The ruf= tag specifies where to send forensic reports (details about individual failing messages). The fo=1 tag tells providers to send forensic reports if either SPF or DKIM fails.
Common DMARC mistake: Setting p=reject before SPF and DKIM are fully configured. If you do this, all misaligned mail bounces, including mail from subdomains you forgot to authenticate. Start with p=none and monitor reports for 2–4 weeks before tightening the policy.
Another mistake: Forgetting to publish DMARC for subdomains. If you send from newsletter@sub.yourdomain.com, you need a DMARC record at _dmarc.sub.yourdomain.com. Otherwise, DMARC fails for subdomain mail.
How to publish: Log into your DNS provider. Add a new TXT record at _dmarc.yourdomain.com. Paste your DMARC policy. Save and wait 24 hours.
Step-by-Step Setup
1. Gather provider information. Contact your mail provider (Mailchimp, SendGrid, HubSpot, etc.) and ask for SPF include, DKIM selector, and DKIM public key. Most providers have a setup guide or automated setup wizard.
2. Log into your DNS provider. This is usually your domain registrar (GoDaddy, Namecheap, Route 53) or your web host. Find the DNS settings for your domain.
3. Add SPF record. Create a new TXT record at your domain root (@ or your domain name). Paste your SPF record with all includes. Use ~all (softfail) initially.
4. Add DKIM record. Create a new TXT record with the name your mail provider specifies (e.g., default._domainkey.yourdomain.com). Paste the full public key value.
5. Add DMARC record. Create a new TXT record at _dmarc.yourdomain.com. Start with v=DMARC1; p=none; rua=mailto:your-email@yourdomain.com.
6. Wait and monitor. DNS changes take 24 hours to propagate. After 24 hours, send a test email and check if it arrives in the inbox. Check your DMARC reports after 24 hours to see pass/fail rates.
7. Tighten DMARC policy. After 2–4 weeks of 100% pass rate, change p=none to p=quarantine or p=reject.
Validation and Troubleshooting
After publishing your records, validate them to catch errors before they affect deliverability.
Validate SPF: Use an SPF record checker (search "SPF record checker"). Enter your domain and verify that all your mail providers appear in the include list. Check that the record does not exceed 10 includes. If it does, contact your mail provider about flattening.
Validate DKIM: Use a DKIM record checker. Enter your domain and the selector your mail provider gave you. The checker should retrieve the public key from DNS. If it returns "not found," the record was not published or the selector is wrong. Double-check the record name in your DNS settings.
Validate DMARC: Use a DMARC record checker. Enter your domain. The checker should retrieve your DMARC policy. If it returns "not found," the record was not published at _dmarc.yourdomain.com.
Test deliverability: Send a test email from your mail provider to a Gmail account, Outlook account, and Yahoo account. Check if it lands in the inbox or spam. If it lands in spam, check your mail provider's bounce report or spam feedback loop to see which authentication check failed.
Troubleshooting DKIM failures: DKIM fails if the selector is wrong, the public key is incomplete, or the DNS record was not saved. Verify the record name and value in your DNS settings. If the value is truncated (cut off mid-key), re-paste the full key and save again.
Troubleshooting SPF failures: SPF fails if a mail provider is missing from the include list or if you exceeded 10 includes. Add the missing provider to the SPF record. If you have too many providers, ask each one if they support SPF flattening or consolidate to fewer providers.
Troubleshooting DMARC failures: DMARC fails if SPF or DKIM fails, or if the domain in the message does not align with the authenticated domain. Fix SPF and DKIM first. If alignment is the issue, check that your mail provider is using your domain (not a subdomain) as the "From" address.
Reality Check: Timing and Scope
DNS propagation takes 24 hours but can take up to 48 hours in some cases. Do not assume your records are live immediately after publishing. Test after 24 hours and again after 48 hours.
DMARC reports arrive once per day, typically in the morning. Do not expect reports until 24 hours after you publish the DMARC record. Reports are XML files that require a parser to read. Some email providers (like Gmail) offer a simplified dashboard; others require you to upload the XML to a third-party tool.
Authentication standards apply to your domain only. If you send from subdomains (e.g., newsletter@sub.yourdomain.com), you need separate SPF, DKIM, and DMARC records for each subdomain. Do not assume parent domain records apply to subdomains.
Changing SPF or DKIM records does not affect mail already in transit. If you fix a record, old failing messages are not retried. Only new messages sent after the fix will use the new record.
What to Do Next
Once your authentication records are live and validated, audit your email deliverability to catch other issues (sender reputation, list quality, content filters). Authentication is foundational; it is not the only factor in inbox placement.
FAQs
Do I need all three standards?
Yes. Most mailbox providers check all three in order. Missing even one can cause deliverability problems. Gmail, Yahoo, and AOL now require DMARC alignment for bulk senders.
What is the difference between SPF softfail (~all) and hardfail (-all)?
Softfail (~all) tells mailbox providers to deliver the mail even if SPF fails, but flag it as suspicious. Hardfail (-all) tells them to reject the mail. Use softfail while testing; switch to hardfail only when you are confident all your mail sources are listed.
Can I use the same DKIM key for multiple domains?
No. Each domain must have its own DKIM key pair. The public key is published in DNS under your domain; if you reuse the same key across domains, mailbox providers will reject it as invalid.
How often should I check my DMARC reports?
Check daily for the first 2–4 weeks after setup. Look for failures and fix them before tightening your DMARC policy. After that, check weekly or monthly to monitor for new issues (like a compromised mail account).
People Also Ask
What happens if I do not set up authentication?
Mailbox providers treat your mail as unverified. It lands in spam, gets rejected, or is flagged for manual review. Large senders (>5,000 messages per day) without authentication are almost always blocked.
Can I use a third-party domain for my SPF record?
Yes, but only for mail services. For example, you can include SendGrid's domain in your SPF record. Do not include random third-party domains; mailbox providers will reject the record as suspicious.
What is DMARC alignment?
Alignment means the domain in the message "From" header matches the domain that passed SPF or DKIM. For example, if your "From" is you@yourdomain.com, the SPF or DKIM check must pass for yourdomain.com (not a subdomain). Misalignment causes DMARC to fail.
Do I need DKIM if I have SPF?
SPF and DKIM serve different purposes. SPF checks the sending server; DKIM signs the message. Use both. If SPF fails, DKIM can still pass and keep your mail in the inbox. If DKIM fails, SPF can still pass. Together, they provide redundancy.
How do I read DMARC reports?
DMARC reports are XML files. Each report shows a count of messages that passed or failed SPF, DKIM, and DMARC alignment. Use a DMARC report parser (like Postmark, Agari, or Valimail) to visualize the data. Look for sources with high failure rates and investigate.
What if my mail provider does not provide DKIM setup instructions?
Ask their support team for the DKIM selector and public key. Most providers have this information in their documentation or in an automated setup wizard. If they do not offer DKIM, switch providers or use a transactional mail service (like SendGrid or Postmark) for critical emails.
Can I test authentication without sending real emails?
Yes. Use online validators (SPF, DKIM, DMARC checkers) to verify your records are published correctly. These tools do not send mail; they only check DNS. However, you should still send test emails to real mailboxes to confirm deliverability.
What is the difference between DMARC p=quarantine and p=reject?
Quarantine sends failing mail to spam. Reject bounces it entirely. Quarantine is safer because legitimate mail from new sources can still arrive (in spam) for review. Reject is stricter and may block mail you intended to receive.
If this post is wrong, outdated, or you would take a different path
I write from work I have done on real sites. Search products change, and a step that was right when I published can go stale. I can also be wrong about the method.
If you disagree with the approach, the facts, or the outcome, I want the detail. Tell me what is off, what you would do instead, and where you saw it. I use that to correct the post so the next reader is not stuck.
This is not a comment thread. Use Contact me so the note is tied to this post and I can reply.
You are sending feedback for
DMARC, DKIM, and SPF: Configure Email Authentication Standards
Email Marketing & Nurture
https://hammadshk.com/blog/dmarc-dkim-and-spf-configure-email-authentication-standards
