How to Set Up SPF, DKIM and DMARC for Email Authentication

Email was designed in an era of implicit trust, which means the "From" address you see in your inbox can be forged with almost no effort. Attackers exploit this to send phishing and spoofed messages that appear to come from legitimate domains, damaging brand reputation and putting recipients at risk. Email authentication is the set of DNS-based standards that lets receiving servers verify that a message genuinely came from your domain.

Beyond security, authentication is now a deliverability requirement. Major mailbox providers such as Gmail and Yahoo require bulk senders to publish SPF, DKIM and a DMARC policy, and unauthenticated mail is increasingly routed to spam or rejected outright. Getting these three records right is the single most effective thing you can do to land in the inbox and keep impersonators out.

Sender Policy Framework (SPF) is a DNS TXT record that lists the servers allowed to send mail on behalf of your domain. The record lives at the root of your domain and always begins with "v=spf1", followed by mechanisms such as "include:", "ip4:", "ip6:", "a" and "mx", and ends with an "all" qualifier. A typical record looks like "v=spf1 include:_spf.google.com include:sendgrid.net -ip4:198.51.100.10 ~all".

The trailing qualifier tells receivers what to do with mail from servers not on the list: "-all" means hard fail (reject), while "~all" means soft fail (accept but mark). Start with "~all" and tighten to "-all" once you are confident every legitimate source is included. After you publish or change the record, verify it with our SPF Check checker to confirm syntax and that it resolves correctly.

SPF has a strict limit of 10 DNS lookups per evaluation. Each "include", "a", "mx", "ptr" and "exists" mechanism counts toward this total, and nested includes count too. Exceeding the limit causes a "permerror", which means your SPF effectively fails even though the record looks fine.

If you use several third-party senders (marketing platform, helpdesk, CRM, transactional provider), it is easy to blow past 10 lookups. Consolidate where possible, replace "include" entries with flattened "ip4" ranges for stable senders, and run your record through the SPF Check tool to count the lookups before they bite you in production.

DomainKeys Identified Mail (DKIM) adds a digital signature to every outgoing message using a private key held by your sending platform. The matching public key is published as a DNS TXT record at "selector._domainkey.yourdomain.com", where the selector is a short label chosen by the sender (for example "google", "s1" or "k1"). The record value begins with "v=DKIM1; k=rsa; p=" followed by the long public key.

Because the signature covers the message body and key headers, DKIM proves the mail was not tampered with in transit and genuinely originates from a domain that controls the private key. Each provider you send through gives you its own selector and key, so you may publish multiple DKIM records. Confirm each one is live and well-formed with our DKIM Check lookup by entering the selector and domain.

Domain-based Message Authentication, Reporting and Conformance (DMARC) builds on SPF and DKIM by telling receivers what to do when a message fails authentication, and by requesting reports on who is sending mail as your domain. It is published as a TXT record at "_dmarc.yourdomain.com" and begins with "v=DMARC1". A starter record looks like "v=DMARC1; p=none; rua=mailto:[email protected]".

DMARC introduces the concept of alignment: a message passes only if the domain validated by SPF or DKIM matches the domain in the visible "From" header. This is what stops spoofers who pass SPF on some unrelated domain from impersonating you. Use the "p" tag to set the policy (none, quarantine or reject), "rua" for aggregate report addresses, and optionally "ruf" for forensic reports. Validate your record with the DMARC Check checker and make sure your MX setup is correct too via the MX Lookup tool.

Never jump straight to a blocking policy. Begin with "p=none", which enforces nothing but turns on aggregate reporting. Collect those "rua" reports for two to four weeks to discover every legitimate source sending as your domain, including services you may have forgotten about, and fix any that are failing SPF or DKIM alignment.

Once your reports show legitimate mail passing consistently, move to "p=quarantine", optionally using the "pct" tag to apply the policy to a percentage of mail (for example "pct=25") and ramp up gradually. After quarantine runs cleanly, advance to "p=reject" for full protection, where failing mail is refused at the gateway. Re-check the record at each stage with the DMARC Check tool to confirm the change propagated as intended.

The most frequent errors are publishing more than one SPF record (a domain may have only one "v=spf1" TXT record), exceeding the 10-lookup limit, and forgetting to add a new sending service to SPF or DKIM after onboarding it. On the DKIM side, watch for keys that are split incorrectly across DNS string segments and selectors that do not match what the provider actually signs with.

For DMARC, the classic mistakes are jumping to "p=reject" without monitoring, omitting the "rua" address so you fly blind, and misunderstanding alignment, especially when third parties send from subdomains. Take advantage of the "sp" tag to control subdomain policy explicitly, and re-test every record after DNS changes since propagation can take time.

Once SPF, DKIM and an enforcing DMARC policy are in place, you can layer on additional standards. BIMI (Brand Indicators for Message Identification) lets your verified logo display next to authenticated mail in supporting clients, but it requires DMARC at quarantine or reject first; check your setup with the BIMI Check tool.

MTA-STS enforces encrypted TLS connections between mail servers to prevent downgrade attacks, and TLS-RPT delivers reports on TLS delivery problems. Validate these policies with our MTA-STS Check and TLS-RPT Check checkers as part of a complete, defense-in-depth email security posture.

Do I need all three of SPF, DKIM and DMARC? Yes. SPF and DKIM provide complementary verification methods, and DMARC ties them to the visible From address while giving you reporting and enforcement. DMARC has nothing to act on unless SPF and/or DKIM are correctly aligned, so all three work together.

Why is my mail still going to spam after authenticating? Authentication is necessary but not sufficient. Deliverability also depends on sender reputation, list hygiene, content, engagement and proper reverse DNS. Authentication removes a major blocker, but poor sending practices can still hurt placement.

How long do DNS changes take to apply? It depends on the TXT record's TTL, but propagation typically completes within a few minutes to a few hours. After publishing, re-run the relevant checker (such as the SPF Check or DMARC Check tool) until it reflects your new value before relying on it.

Can I have more than one DKIM record? Yes. You can publish a separate DKIM key under a different selector for each sending platform, and they coexist without conflict. SPF, by contrast, must be a single combined record per domain.

Is it safe to set p=reject immediately? It is risky. Without a monitoring period at p=none you may unknowingly block legitimate mail from forgotten services. Always observe aggregate reports first, then ramp through quarantine before enforcing reject.