Authenticate your domain
Set up SPF, DKIM and DMARC for your sending domain, verify the records pass, and fix the three things that usually go wrong.
On this page›
Authentication proves to a receiving mail server that a message claiming to come from your domain really did come from you. Without it your mail is anonymous, and large providers filter anonymous bulk mail aggressively. When you finish this page your domain will have SPF, DKIM and DMARC records published, and the Sending domains screen will show the domain as verified.
Before you start
You need access to the DNS records for your domain. That is usually the registrar you bought the domain from, or wherever your nameservers point: Cloudflare, Route 53, your hosting control panel. If somebody else manages DNS for you, this page is the one to send them.
What each record proves#
The three records answer three different questions. You need all three.
SPF answers "is this server allowed to send for this domain?" It is a DNS record listing the mail servers authorized to send on your behalf. A receiver sees mail arriving from a server, looks up your SPF record, and checks whether that server is on the list. SPF authorizes senders. It says nothing about the message itself.
DKIM answers "has this message been altered since it was sent?" Outgoing mail is signed with a private key, and the matching public key is published in your DNS. The receiver verifies the signature against that published key. If the signature checks out, the message is intact and genuinely signed by the holder of your key. If anything was tampered with in transit, the signature fails.
DMARC answers "what should I do when the other two fail?" It is a policy record you publish that tells receivers how to treat mail from your domain that does not pass SPF or DKIM, and where to send reports about it. DMARC also enforces alignment, meaning the domain that passes SPF or DKIM has to match the domain in the From address a reader sees. That alignment requirement is what makes DMARC worth having: it closes the gap where somebody passes authentication for their own domain while displaying yours.
Add the records#
Open Sending domains and add your domain
Go to Sending domains and add the domain you will send from. Enter it without a protocol or a mailbox, so example.com or mail.example.com, not https://example.com and not you@example.com.
Read the record values off the screen
Once the domain is added, the screen shows you the exact DNS records to publish, including the record type, the host or name, and the value for each. Use those values. Do not copy record values from a blog post, another provider's documentation, or another domain you set up previously. The DKIM value in particular is specific to your domain and cannot be reused.
Publish the records at your DNS provider
Open your DNS provider and create each record exactly as shown. Three details cause most failures:
- Copy the whole value. DKIM values are long. Select the full string, not what fits on the visible line.
- Watch how your provider handles the host field. Some expect the full hostname, some expect only the part before your domain and append the rest for you. Entering the full hostname at a provider that appends will produce a record at the wrong name.
- Leave TTL at the default unless you have a reason. A low TTL only helps while you are still changing records.
Publish a DMARC policy
DMARC is a TXT record at the _dmarc host on your domain. Start with a monitoring policy, which is the p=none setting, plus a reporting address you can receive mail at:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the reporting address with your own. This publishes a valid DMARC policy without changing how any of your mail is handled, which is exactly what you want at the start.
Verify from the Sending domains screen
Come back to Sending domains and run the verification check. It queries DNS for each record and shows you which pass. If a record is not found yet, wait and check again rather than editing a record that is already correct.
Send one test message and read the headers
Send a single message to an address at a large mailbox provider and view the original message or the full headers. You are looking for the authentication results line reporting spf=pass and dkim=pass, with dmarc=pass alongside them. This confirms end to end what the DNS check confirms in isolation.
Troubleshooting#
Verification fails but the record looks correct
DNS changes do not appear everywhere at once. Propagation usually takes minutes and can take up to 48 hours depending on the previous TTL and your provider. If you have checked the value character by character and it is right, wait an hour and verify again.
Two other common causes: a trailing space copied into the value, and smart quotes if the value passed through a document or a chat client on its way to you. Retype rather than repaste if you suspect either.
More than one SPF record on the domain
A domain must have exactly one SPF record. This is the rule people break most often, usually by adding a second record when a new sending service asks for one, leaving the old one in place. Two SPF records do not combine. Receivers treat the result as a permanent error and SPF fails entirely, including for the service that was working yesterday.
The fix is to merge them. Keep one TXT record starting with v=spf1, containing the authorization mechanisms from every service you send through, ending with the single closing mechanism. Delete the other record. Check for this before you conclude that a value is wrong.
DMARC and when to tighten it
Leave the policy at p=none for at least a few weeks while you read the reports arriving at your reporting address. You are looking for sources sending as your domain that you did not know about: a helpdesk, an invoicing system, a form on your website. Each of those needs to be authenticated too, or its mail will be affected when you tighten the policy.
Once the reports show only sources you recognize and they all pass, move to p=quarantine, and later to p=reject if you want unauthenticated mail refused outright. Going straight to p=reject on day one is how people accidentally stop their own invoices from being delivered.
Last updated September 10, 2026