SPF DKIM DMARC: How to Set Up and Troubleshoot Email Authentication

A new transactional email provider can start sending on your behalf before anyone updates your DNS. The result may be a message that passes one authentication check but fails DMARC—or gets filtered despite passing all three. This guide explains spf dkim dmarc and gives you a safe, provider-neutral setup path for every service that sends as your domain.

SPF lists authorized sending sources, DKIM lets recipients verify a cryptographic signature, and DMARC checks whether SPF or DKIM aligns with the domain in the visible From address. Publish records for every legitimate sender, test real messages, and begin DMARC monitoring before enforcing a stricter policy. Authentication helps defend your domain against spoofing, but does not guarantee inbox placement.

SPF, DKIM, and DMARC at a glance

Each protocol answers a different question. Together, they help a receiving mail server assess whether a message is authorized to use your domain. The reference point for DMARC is the domain in the visible From address—the one a recipient sees, not necessarily the address used to handle bounces.

An SPF record is published in DNS, but an SPF result applies to the envelope sender, not automatically to the From address customers recognize. DKIM signatures identify a signing domain through the d= value. DMARC connects those technical identities to the visible From domain and lets the domain owner set a policy for failures.

How SPF, DKIM, and DMARC work together

SPF authorizes sending infrastructure. When a receiving server evaluates a message, it checks whether the connecting server is permitted to send for the domain in the message's envelope sender. If a company uses Google Workspace, an application provider, and a campaign service, each sender needs to be considered in the domain's SPF design.

DKIM works at the message level. A sender adds a signature, and the recipient looks up the public key using the signature's selector and signing domain. If the signed content has been changed in transit, verification may fail. Unlike SPF, DKIM can often remain valid after forwarding, provided the signed content is not altered.

DMARC passes when at least one of these combinations passes: SPF authentication plus SPF alignment, or DKIM authentication plus DKIM alignment. Passing SPF alone is not enough if its authenticated domain does not align with the visible From domain. The same is true of a valid DKIM signature whose d= domain is unrelated to that From domain.

For example, a service could send a message showing From: receipts@example.com while using its own domain for the envelope sender and DKIM signature. SPF and DKIM might each pass for the service's domains, yet neither result aligns with example.com; DMARC therefore fails. Configure a custom aligned domain or DKIM signing for the sender when the provider supports it.

Why email authentication matters—and what it cannot fix

Authentication makes it harder for someone to impersonate your domain and gives recipient systems signals to evaluate legitimate messages. DMARC also provides reporting that can reveal senders using your domain, including systems your team may have forgotten. Gmail's sender guidelines specify authentication requirements for senders, with additional SPF, DKIM, and DMARC requirements for those sending more than 5,000 messages a day to Gmail accounts.

Authentication is not a reputation score or a content review. A message can pass SPF, DKIM, and DMARC and still be placed in spam because of recipient complaints, sending patterns, message content, or other filtering signals. Conversely, a business security filter may reject an unauthenticated message even if a recipient tries to allowlist it. Treat authentication as a necessary identity control, not an inbox guarantee.

Mailgun's State of Email Deliverability report found that 66.2% of surveyed senders said they used both SPF and DKIM, while 25.7% were unsure about their setup. That uncertainty is a practical reason to inspect actual DNS and message results rather than assuming a service configured authentication on your behalf.

Before setup: list every service that sends email for your domain

Start with an inventory, not a DNS edit. List business email, account notifications, password resets, invoices, marketing campaigns, support platforms, monitoring alerts, and any vendor sending from your domain. Include test, staging, and legacy systems if they send real mail.

For each service, record the visible From domain, envelope or bounce domain, DKIM signing domain, and who controls its DNS instructions. Ask whether it supports custom DKIM and an aligned return-path domain. Those details determine whether its messages can pass DMARC and which records you need.

This step matters because publishing an incomplete SPF policy can cause legitimate services to fail SPF. Adding a second SPF record later is not the fix: receivers generally expect one SPF record per domain, and multiple records can produce a permanent error. Inventory first, then consolidate the authorized sources into one record.

How to configure SPF, DKIM, and DMARC

Use this sequence for a new domain or a domain adding another email provider. Exact record values depend on the sending service and DNS host; do not copy a vendor's example value into a different provider's setup.

1. Inventory senders. Confirm which services send mail and the domains they use for From, envelope, and DKIM.
2. Publish one SPF TXT record. Combine the authorization mechanisms required by all legitimate senders into a single SPF record at the relevant domain. Avoid adding multiple independent SPF records. SPF also has a limit of 10 DNS-querying terms during evaluation, so nested provider includes can make an otherwise plausible record fail.
3. Enable DKIM for each sender. A provider may give you a selector and a DNS record, or ask you to publish a CNAME that points to its key. Add the record at the exact host it specifies. Different senders can use different selectors; selectors help recipients find the right public key.
4. Send test messages and inspect alignment. Test each sending path, not just a message from your main inbox. Check authentication results and confirm that at least one passing SPF or DKIM domain aligns with the visible From domain.
5. Publish DMARC in monitoring mode. Add a DMARC TXT record at _dmarc.yourdomain.com with a reporting destination you control and an initial p=none policy. Use reports to find legitimate sources that are failing before asking receivers to quarantine or reject them.
6. Enforce in stages. Fix identified senders, watch reporting for changes, and then consider a gradual move to p=quarantine or p=reject. Make changes in small steps so a forgotten invoice tool does not disappear into quarantine unnoticed.

DNS changes can take time to appear consistently because resolvers cache records. Check the authoritative record and allow for the DNS host's TTL and provider activation process before treating a new record as broken. Google's DMARC setup guidance recommends establishing SPF and/or DKIM before publishing DMARC, giving authentication changes time to take effect.

What DMARC alignment and policies mean in practice

Alignment compares the authenticated domain with the domain in the visible From address. In relaxed mode, related organizational domains can align; in strict mode, the domains must match exactly. For example, mail.example.com can align with example.com under relaxed alignment, but not under strict alignment. The DMARC record controls SPF and DKIM alignment separately with the aspf and adkim tags.

The policy tag tells receiving systems what to do with messages that fail DMARC:

• p=none requests monitoring without asking receivers to apply a DMARC failure action.
• p=quarantine asks receivers to treat failing messages as suspicious, often placing them in spam.
• p=reject asks receivers to reject failing messages.

Policy is not a switch that repairs records. A sender can have an SPF pass for a provider-owned envelope domain and still fail DMARC if DKIM also fails or does not align. Amazon SES documents this distinction: SPF and DKIM results must align with the From domain for DMARC, and SES describes configuring DKIM signing or a custom MAIL FROM domain as ways to address alignment. Apply a stricter policy only after you understand the report data and have tested each sender.

How to check records and troubleshoot failures

Check DNS records and actual message headers. A DNS lookup can confirm what is published, but a real message shows what a particular provider actually signed and which domains the recipient evaluated. Look for Authentication-Results, Return-Path, DKIM-Signature, and the DMARC result in the received message headers.

Troubleshoot in this order:

• SPF missing or failing: Confirm the record exists at the envelope-sender domain and includes the sending provider. Check for multiple SPF TXT records and excessive DNS lookups from nested include mechanisms.
• DKIM missing or failing: Compare the selector in the s= tag and signing domain in d= with the DNS record. A root-domain key does not prove a sender signing as a subdomain has its key configured.
• DMARC fails while SPF or DKIM passes: Compare the passing identity to the visible From domain. Authentication without alignment is not a DMARC pass.
• Third-party mail is rejected: Confirm that the provider's DNS setup was completed and that the message uses your aligned DKIM or envelope domain. Allowlisting may not override a recipient's authentication policy.
• Results vary between messages: Check every sending stream separately. A campaign service and an application notification service may use different selectors, return paths, or From subdomains.

A result such as spf=pass does not on its own mean DMARC passed. Read the DMARC result and the authenticated domain alongside the SPF and DKIM outcomes. If you manage multiple domains or tools, retain a simple sender-to-record map so the next DNS change does not silently remove a legitimate source.

Common setups: Google Workspace, Microsoft 365, and Amazon SES

Google Workspace, Microsoft 365, and Amazon SES each have provider-specific activation steps and DNS values. For Google Workspace, configure SPF and turn on DKIM for the sending domain in the admin console, then publish the DMARC policy. Google notes that senders to personal Gmail accounts should use SPF, DKIM, and DMARC; its bulk-sender criteria require all three, while DMARC can initially use p=none.

For Microsoft 365, follow Microsoft's current custom-domain instructions for SPF and DKIM, then add the domain's DMARC TXT record. If other tools also send from the domain, coordinate their authorization and signing with Microsoft 365's records instead of replacing them with a second SPF entry.

Amazon SES requires its own domain identity and sending configuration. Depending on the setup, SES can provide DKIM records and options for a custom MAIL FROM domain. Review the SES identity's records and test DMARC alignment: an SES SPF pass for an SES-controlled return path may not align with the visible From domain. AWS's DMARC guidance for SES explains both SPF and DKIM alignment paths.

If you send through Volanea, every Volanea email goes over Amazon SES. We provide guided SPF, DKIM, and DMARC domain setup and automatically check authentication, but your DNS still needs to represent all the other services that send for your domain. See Volanea's Amazon SES comparison for how domain setup works in our platform, or learn about the email platform that combines transactional email, campaigns, and automations on one API.

FAQ

Does DMARC require both SPF and DKIM to pass?

No. DMARC passes when at least one aligned method passes: SPF authentication and alignment, or DKIM authentication and alignment. Using both is still the more resilient setup. For example, forwarding can disrupt SPF, while a message alteration can invalidate a DKIM signature, so having both gives recipient systems two possible aligned paths.

Why does my message fail DMARC when SPF says pass?

SPF evaluates the envelope-sender domain, which can differ from the visible From domain. If the message passes SPF for a vendor's domain but the From address uses your company domain, SPF may not align. Check the Return-Path, the DMARC result, and whether DKIM passes with an aligned d= domain.

When should I change DMARC from p=none to p=reject?

Move toward enforcement when reports show that legitimate senders are accounted for and test messages from each service pass DMARC. There is no universal number of days that makes a domain ready: campaign schedules, transactional volume, and reporting delays vary. Make staged policy changes and monitor for unexpected failures after each one.

If all three checks pass, why is email still going to spam?

Authentication confirms domain-related identities; it does not certify message quality or recipient interest. A message can pass SPF, DKIM, and DMARC and still be filtered based on recipient complaints, sending history, content, or other mailbox-provider signals. Investigate those factors separately rather than changing valid DNS records without evidence.

Start free with 1,000 emails a month → https://app.volanea.com/signup