Verify your sending domain before you send real mail. Verification proves that you control the domain and lets your sending platform sign messages as you, so receivers can check that mail from your address is genuine. It involves a few DNS records, a short wait and a test. This guide explains what each record does, how to publish it, how to check it and how to fix the problems that most often stop verification from completing.
Record names and values come from your platform. This guide explains the concepts and the checks that apply to any sender. Use the exact host names and values shown in your own account when you publish records, and copy them rather than retyping them.
What verification actually checks
Receiving servers decide whether to trust a message from the evidence in its headers and in DNS. A sending platform needs your DNS to say three things: that its servers may send for your domain, that its signing key is yours to use, and what receivers should do with mail that fails. Verification is the platform checking that those records exist where it expects to find them, which can only be true if someone with control of the DNS put them there.
| Record | Purpose | Where it lives |
|---|---|---|
| SPF (TXT) | Lists which servers may send for the domain used in the envelope | The domain or return-path subdomain |
| DKIM (TXT or CNAME) | Publishes the public key used to verify message signatures | selector._domainkey.yourdomain |
| Return-path (CNAME or MX) | Receives bounces and aligns SPF with your domain | A subdomain such as bounce.yourdomain |
| DMARC (TXT) | Tells receivers how to treat mail that fails authentication, and where to send reports | _dmarc.yourdomain |
| Tracking domain (CNAME), optional | Brands click and open links with your domain | A subdomain such as links.yourdomain |
For the theory behind each record, see our guide to authenticating a sending domain. Here the focus is on the practical steps of getting the records in place and confirming that they work.
Step 1: Decide which domain to send from
Pick the domain that will appear in the From address. Many senders use a dedicated subdomain for each mail stream, for example one for transactional messages and another for marketing. The advantages are separate reputations, so a problem with promotional mail does not damage password resets, and a clean place to start DMARC enforcement without touching the root domain that your staff use. The cost is a little more DNS work. If you are unsure, start with a subdomain.
Avoid free mailbox domains. You cannot authenticate mail sent from addresses at consumer mailbox providers, because you do not control their DNS. Gmail, Yahoo and others also reject or distrust bulk mail sent that way. Send from a domain you own.
Step 2: Add the domain in your sending platform
In your account, add the domain you chose. The platform will show a list of DNS records, each with a type, a host name and a value. Keep that page open, because you will copy from it. If you plan to send from several domains, add them one at a time and finish each before starting the next, so records do not get mixed up.
Step 3: Publish the records at your DNS provider
- Open the DNS zone. Sign in to the registrar or DNS host that controls the domain, and open the zone editor.
- Add each record. Create one record per row from the platform: select the type, enter the host name and paste the value.
- Mind the host name. Many providers add your domain automatically, so enter only the part before it. Writing the full name can produce selector._domainkey.example.com.example.com.
- Edit SPF rather than adding a second one. If the domain already has an SPF record, add the platform include mechanism to it instead of creating another record.
- Keep values intact. Do not add spaces, line breaks or extra quotes. Long DKIM keys may need to be split into several quoted strings, which most providers do for you.
- Save and note the time. Record when you saved, because propagation is measured from then.
A merged SPF record
A domain that already sends through its mailbox provider and now adds a sending platform should end up with one record that contains both includes:
v=spf1 include:_spf.mailprovider.example include:spf.sendingplatform.example ~allThe two include names above are placeholders. Use the real values for your services, and remember that each include counts toward the limit of ten DNS lookups, which we explain in our guide to fixing SPF permerror.
Step 4: Wait, then check from outside
DNS changes are not instant. Each record has a time to live, or TTL, which says how long resolvers may cache the answer. A new record normally appears quickly because there is nothing cached, while a changed record can take up to the old TTL to be seen everywhere. While you wait, avoid making further changes to the same record, since each edit restarts the clock.
To check your records, query them from somewhere other than your own router, which may hold stale data. Use a public lookup tool or the command line:
dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short CNAME bounce.example.com
dig +short TXT _dmarc.example.comEach command should return the value you published. If it returns nothing, the record is missing, misnamed or not yet propagated.
Step 5: Run the verification and read the result
Ask the platform to verify the domain. A successful result usually marks each record as found. A failure message normally says which record could not be matched, and that tells you where to look. Work through them one at a time rather than changing everything at once.
| Symptom | Likely cause | What to do |
|---|---|---|
| Record not found | Wrong host name, doubled domain or not yet propagated | Query the exact name with dig, correct the host and wait for the TTL |
| Value does not match | Extra space, truncated paste or altered quotes | Delete the record and paste the value again, then compare |
| Two SPF records | A new record was added beside the old one | Merge both into a single record and delete the other |
| SPF permerror | More than ten DNS lookups or a syntax error | Remove unused includes and check syntax |
| DKIM key not found | Selector typed incorrectly or CNAME missing | Check that the selector in the signature matches the DNS name |
| CNAME conflicts with another record | A CNAME cannot share a name with TXT or MX records | Use a dedicated subdomain for the CNAME |
| Verified, but mail fails DMARC | The From domain and the signing or return-path domain do not align | Send from the verified domain and align DKIM or SPF |
Step 6: Prove it with a real message
Verified records are necessary, not sufficient. Send a test message to an address you control at a large mailbox provider and open the full headers. Look for the authentication results line and confirm three passes: SPF, DKIM and DMARC. Then check alignment, meaning that the domain in the From address matches the domain that passed SPF or DKIM. A message can pass SPF for the platform domain and still fail DMARC for yours if nothing aligns.
Authentication-Results: mx.example.net;
dkim=pass header.d=mail.example.com;
spf=pass smtp.mailfrom=bounce.mail.example.com;
dmarc=pass header.from=mail.example.comIn the example, DKIM passes for the same domain as the From address, so DMARC passes by DKIM alignment. If your result shows a failure, our spam troubleshooting checklist lists what to check next.
Step 7: Add DMARC and plan enforcement
Publish a DMARC record even if your first policy only monitors. A cautious starting point is a policy of none with a reporting address, which tells receivers to deliver mail as before while sending you daily summaries of who is sending as your domain:
_dmarc.mail.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Read the reports for a few weeks, fix any legitimate source that fails, and only then move to quarantine and reject. Our guide to reading DMARC reports and moving to reject explains the path. Moving to enforcement too early risks blocking your own mail.
Good habits after verification
- Keep a record of your DNS. Export or screenshot the zone before and after changes, so you can restore it quickly.
- Use one owner for DNS changes. Many outages are caused by two people editing the same record.
- Re-check after migrations. Moving DNS hosts or registrars often drops records that are not copied across.
- Lower TTLs before planned changes. Reducing the TTL a day in advance makes a later change take effect quickly.
- Monitor continuously. A scheduled check that the records still resolve will catch accidental deletion before mail fails.
When to ask for help
If every record matches and verification still fails after the TTL has passed, send support the domain name, a screenshot of the zone and the error message shown. Do not share DNS account credentials. With those details the cause is usually found in one reply.
Stuck on a DNS record? Send us the domain and the error you see and we will tell you which record to correct.
Further reading and sources
Frequently asked questions
What does it mean to verify a sending domain?
It means proving you control the domain by publishing DNS records that your sending platform can find. Once the records are in place, the platform can sign mail with DKIM for your domain and you can send from addresses at that domain without them looking forged to receivers.
How long does domain verification take?
Often a few minutes, but it can take up to the time to live of the records you changed, and occasionally longer if an old record is cached. Most platforms let you re-check as often as you like, so wait, test from outside your network and try again.
Should I verify my root domain or a subdomain?
A subdomain such as mail.example.com is usually safer for bulk and transactional mail because its reputation is separate from the root domain used for staff email. Use the root domain only when you have a clear reason and a plan to authenticate every system that sends as it.
Why does verification fail even though I added the records?
The usual causes are a record added at the wrong name, the domain appended twice by the DNS provider, a stray space or quote in the value, a record that has not propagated, or an existing SPF record that was duplicated instead of edited. Compare each record character by character with what the platform shows.
Can I have more than one SPF record?
No. A domain must publish a single SPF record, and having two causes a permanent error. If you send through several services, merge their includes into one record and keep it under the limit of ten DNS lookups.
Do I need DMARC to send mail?
Technically you can send without it, but large mailbox providers now expect bulk senders to publish DMARC, and without it your domain can be spoofed more easily. Start with a monitoring policy and move to enforcement when reports show all your mail passing.
Will verifying my domain affect my existing email?
Not if you add records correctly. Adding DKIM and return-path records for a sending service does not change where your staff email is delivered. The one risk is editing your SPF record, so change it carefully and keep your existing includes.
What if I cannot access my DNS settings?
You need access to the DNS zone, held by your registrar or DNS host. Ask whoever manages it to add the records, and send them the exact names and values. Do not share account passwords; send the list of records instead.
Do I need to repeat verification later?
The records stay valid until they are removed or changed. Re-check them after DNS migrations, registrar changes or when you rotate DKIM keys, because a missing record will quietly start failing authentication.