How to set up SPF, DKIM, and DMARC for your sending domain

It's way too common to overlook email authentication when you set up automated email. You connect your email provider, send a test message, and it lands in spam. Or Gmail bounces it with a 550 5.7.26 error about an unauthenticated sender. This guide explains how a sending domain is authenticated, which helps keep your messages out of spam.The three key email security components are SPF, DKIM, and DMARC. They let receiving mail servers check whether a message is authorized to use your domain, and they work together: SPF authorizes the sending server's IP address, DKIM adds a cryptographic signature to prove message integrity, and DMARC uses both results to check alignment with the visible sender address and enforce your policy. [1, 2] Getting them right won't guarantee inbox placement, but a missing record can keep ordinary mail from arriving. Password resets and invoice sends need these checks just as much as newsletters do.Gmail's sender guidelines require SPF or DKIM even for small senders, and all three for senders reaching roughly 5,000 messages a day to personal Gmail accounts. We suggest you set them up right away when you connect your domain.We'll use Mailfully's domain setup here to show how everything works. If you use another provider, the record values will differ, but you'll make the same two checks: are the records published correctly, and does a message sent through your app actually pass?What you're setting upWhen your message arrives, the receiving mail server asks three questions. Each record answers one:SPF (Sender Policy Framework): Was the server that delivered this message allowed to send for this domain?DKIM (DomainKeys Identified Mail): Did this message really come from this domain, and did it arrive unchanged?DMARC (Domain-based Message Authentication, Reporting, and Conformance): Do those answers apply to the address the recipient sees in the From line? If not, what should happen to the message?All three are DNS records: short pieces of text published at your DNS host, such as Cloudflare, that any mail server can look up.The diagram below follows one message from your email provider to the receiving server. It shows which part of the message each check reads, which DNS record the server looks up for it, and what happens when DMARC passes or fails.Notice that each check reads a different domain from the same message. SPF uses the Return-Path, DKIM uses the signature's d= domain, and DMARC uses the From address. Most setup problems come from one of those domains not being the one you expected. The table puts the same information in one place: Record What it checks Which domain it checks Where it's published SPF The sending server is on the allowed list The Return-Path (envelope sender) A TXT record at the Return-Path domain DKIM The message carries a valid signature The d= domain in the signature A record at <selector>._domainkey.<domain> DMARC SPF or DKIM passed for a domain that matches the From The domain in the visible From address A TXT record at _dmarc.<domain> SPF: which servers can send for youSPF is a list of servers allowed to send mail for a domain, published as a DNS TXT record. When a message arrives, the receiving server compares the IP address that delivered it against that list. If the address is on the list, SPF passes. If it isn't, SPF fails or softfails, depending on how the record ends.Example SPF for host example.com:v=spf1 include:_spf.google.com ~allThe part that's easy to miss is which domain SPF checks. It doesn't look at the From address your recipient sees. It checks the envelope sender, also called the MAIL FROM or Return-Path. That's a separate address used behind the scenes, mostly so bounce messages have somewhere to go. Recipients don't see it unless they open the raw message, and email providers often set it to their own domain by default.Think of a letter in an envelope. The postal service uses the return address on the envelope; the reader sees the letterhead inside. SPF checks the envelope, not the letterhead.SPF is also tied to the server that hands over the message. When mail is forwarded, the forwarding server becomes the one delivering it, and it usually isn't on your list, so SPF often fails after forwarding.DKIM: a signature that proves the message is yoursDKIM works like a tamper-evident seal. When your provider sends a message, it signs it with a private key that only the provider holds and adds the signature to the message as a header. The matching public key is published in your DNS, so any receiving server can look it up and check the signature.DKIM example on host s1._domainkey.example.com:v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3Xk...IDAQABIf the signature checks out, the receiver knows two things. The message was signed by someone who controls the key for that domain, and the signed parts haven't changed along the way. The signed parts are the body and a set of headers that always includes From and usually includes Subject. If any of them were altered in transit, the check fails.Each signature names the domain it signs for in its d= field. That's the domain the receiver looks up, and it's the domain DMARC later compares to your From address. A single message can carry several DKIM signatures, each for a different domain.DMARC: tying it all to the From addressSPF and DKIM have a gap when used alone: neither one checks the From address your recipient sees. A spammer can send mail through their own server, with SPF passing for their own Return-Path domain and a DKIM signature for their own domain, and still put your domain in the From line. Both checks pass, just for the wrong domain.DMARC closes that gap by connecting the checks to the domain in the visible From address. For a message to pass DMARC, at least one of SPF or DKIM must pass and use a domain that matches the From domain. That match is called alignment.DMARC example on host _dmarc.example.com:v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=r; pct=100Alignment doesn't have to mean identical. Under the default, relaxed rules, any two domains that share the same organizational domain align. The organizational domain is the part you'd buy from a registrar, such as example.com. So mail.example.com and send.mail.example.com align with each other, but neither aligns with example.net.For example, a message from [email protected] can pass DMARC through SPF on send.mail.example.com. An SPF pass on your email provider's own domain won't do it. The same applies to DKIM: a valid signature from an unrelated provider domain doesn't authenticate your From address for DMARC.This explains the otherwise confusing result where SPF and DKIM both say “pass,” but DMARC says “fail.” The checks can succeed for the wrong domains.DMARC also tells receivers what to do with mail that fails (p=none, p=quarantine, or p=reject), and it can ask them to send you reports, which is how you find senders you forgot about. Step 3 covers both.Before you open your DNS settingsChoose the domain you'll send from. For app mail, a subdomain such as mail.example.com is a good place to start. It gives you room to configure sending without mixing those records into the setup you use for staff email. We cover that choice in Send your transactional mail from a subdomain.We'll use mail.example.com throughout this guide. Replace it with your own sending domain, and copy the actual record values from your provider. The DKIM selectors below are examples; publishing them won't verify your domain.You'll need access to the service that hosts your DNS. That might be your registrar, but it could also be Cloudflare or another host. If you're unsure, this command shows your domain's nameservers:bashdig NS example.com +short In Mailfully, add your domain from the Domains page. You'll get a list of records, with a copy button and a status for each one. Keep that page open while you work through your DNS settings. If your DNS is on Cloudflare, Mailfully can add these records for you; see If your DNS is on Cloudflare at the end.Step 1: add the DKIM recordsMailfully gives you three DKIM CNAME records. Each points to a public key hosted by Mailfully, which means keys can rotate without another round of DNS edits on your side. Type Name Value CNAME k7qz2._domainkey.mail.example.com k7qz2.dkim.mailfully.com CNAME m4tr9._domainkey.mail.example.com m4tr9.dkim.mailfully.com CNAME p2xw8._domainkey.mail.example.com p2xw8.dkim.mailfully.com Pay attention to the Name or Host field. Some DNS hosts expect the full name; others append your zone name for you. If you're editing the example.com zone and the form appends example.com, enter k7qz2._domainkey.mail. Entering the full name in that kind of form can produce this:textk7qz2._domainkey.mail.example.com.example.com That's a valid place to publish a record, but no receiving server will look there for your DKIM key. Check the saved record's full name before waiting for verification.If you use Cloudflare, set these CNAMEs to DNS only, shown by the grey cloud. The proxy is for web traffic and prevents the CNAME from resolving to the DKIM target as intended.Check each saved record, using the selector from your dashboard:bashdig CNAME k7qz2._domainkey.mail.example.com +short The answer should match the target value. If it's empty, check the saved name and record type first. The change may also need time to become visible through your DNS provider.Step 2: set up SPF on the return pathMany email providers use their own domain for the Return-Path unless you configure a custom one. SPF can pass in that setup, but it won't align with your From domain. Your mail can still pass DMARC through aligned DKIM; setting up a custom MAIL FROM gives it another way to pass.For example, Mailfully uses send. by default. For our sending domain, that makes the MAIL FROM domain send.mail.example.com. You need an MX record and a TXT record at that name: Type Name Value