How do I authenticate my email? The setup steps, and what an agent does

The short version

To authenticate your email you publish three DNS records, SPF, DKIM, and DMARC, that let receiving servers verify mail from your domain is genuine. It is the first job in any email deliverability effort, because filters weigh reputation against an identity they can verify, and email authentication is what supplies that identity. An AI agent can add the domain, hand you the exact records and verify them, but a person should approve every DNS change.

This page covers the setup steps, in order, for one sending domain. For what each record asserts, see what email authentication is.

What changes when an AI agent sets up email authentication

Ask an agent to authenticate a domain, over MCP or in code, and it will draft all three records. Speed is not the risk. The risk is a record that looks right and breaks mail the domain already sends, such as a second SPF record, DMARC at p=reject on day one, or a DKIM key at the wrong host. Each one is covered in where it goes wrong below.

An agent should verify by reading public DNS for each host name, not by trusting the DNS host's screen, which shows a record as saved before receivers can see it.

• Work on a sending subdomain. On mail.example.com an agent can write SPF, DKIM and DMARC and check alignment without touching everyday mail on the root domain. DMARC there can move to quarantine and then reject once reports show every legitimate sender aligned and DKIM-signed.
• Stop at quarantine on the root domain. On a domain people use for everyday mail and mailing lists, quarantine is safer, because lists rewrite messages and break alignment.

The steps

Three records. SPF and DKIM can go in either order, but DMARC comes last because it checks the other two. If the roles of the authentication protocols are not yet clear, read those first, since the steps below assume you know what each record asserts.

1. Publish an SPF record listing your sending sources, keeping under the ten-lookup limit.
2. Enable DKIM with your sending provider and publish the keys they give you.
3. Add a DMARC record at p=none to start, then tighten to quarantine and reject once reports show only your legitimate mail passing.
4. Send one real test message and check its Authentication-Results header for spf=pass, dkim=pass and dmarc=pass, since a pass without alignment still fails DMARC. A spam test email adds a content check on top.

Two setup errors that block your own mail

Both of these block mail even when every record is published:

• Jumping to p=reject before monitoring. Start at p=none, read the DMARC reports, confirm all your legitimate senders pass, then tighten. Going straight to reject blocks your own mail.
• Assuming the records work without checking a real message. To confirm a live message passes, open a delivered copy and read its headers using the Gmail header check.

Worked example: an agent authenticates a new sending domain

The prompt: "Set up email authentication for mail.example.com so the app can send from it. Show me every DNS change before it goes live."

Before. Left unguided, an agent writes a new SPF record over the one already there, sets DMARC to p=reject, and reports success because the DNS host shows the records as saved.

After. With the Nitrosend MCP tools, the agent works through a fixed sequence:

1. nitro_get_status reads account readiness and the current sender identity, so the agent knows whether a sending domain already exists.
2. nitro_manage_domains adds mail.example.com as a customer sending domain, and the agent lists the DNS records the person needs to publish.
3. A person publishes those records at the DNS host, merging the SPF include into any existing record rather than adding a second one.
4. nitro_manage_domains verifies the domain. If one record fails, its diagnose action points to it, and the agent compares the record with what public DNS returns.
5. nitro_configure_account sets an address on the verified domain as the default sender and keeps the person's own inbox as the test recipient.
6. nitro_manage_template creates a short plain-text template to carry the header check.
7. nitro_review_delivery validates the header-check template and runs its preflight. Nothing is sent at this step.
8. nitro_send_test_message mails the template once to that inbox. The person opens the message headers and looks for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results line.
9. With all three passing, the person decides when DMARC moves off p=none, and nitro_get_insights shows delivery trends once real mail flows.

Where it goes wrong when an agent authenticates email

• Two SPF records, so both fail. An agent told to add a new sender often writes a fresh v=spf1 record instead of adding an include to the one already there. Receivers treat more than one SPF record on a host as a permanent error (RFC 7208, section 4.5), so the old sender and the new one both lose SPF. Merge every include into one record.
• SPF past ten DNS lookups. Each include costs lookups, and an agent that adds one for every tool it wires up can push the record over the limit of ten (RFC 7208, section 4.6.4). SPF then returns a permanent error with no warning at the DNS host. How SPF works in detail covers flattening and include chains.
• A DKIM key at the wrong host. Many DNS hosts add the zone name to whatever is typed in the host field. An agent that pastes the full name selector._domainkey.example.com ends up with example.com added a second time, so receivers never find the key.
• A From domain that does not match the DKIM domain. The agent verifies mail.example.com, then the code it writes sends from an old default address on another domain. DKIM passes for the signing domain, but DMARC fails because the From domain is not aligned with it.
• DMARC reports sent to an inbox nobody reads. A model fills in rua=mailto: with a made-up or unwatched address. The reports that would show when it is safe to tighten never reach anyone, so the policy stays at p=none or gets tightened blind.

How Nitrosend does it for you

Nitrosend auto-configures DKIM, SPF and DMARC for a sending domain, as its ChatGPT integration page notes.

A filtered password reset has no second send, so the transactional email path is where a failed record hurts first. Sending through an email API does not remove the DNS work either, since the records live on your domain and the provider only supplies the keys to publish.

Over MCP the same work is a tool call. nitro_manage_domains adds, verifies, diagnoses, lists and removes customer sending domains, so an agent can run the checks while a person approves the DNS changes. If a domain will not leave the verifying state, see a domain stuck verifying. For the sending side, see the transactional email API and email for Claude.

FAQ

Go deeper