Anyone can send email as your domain. Two DNS records mostly fix that

Of all the findings we report, this is the one people ask about least and should probably ask about more. The worst case is specific: someone emails your users from your domain, the message lands in the normal inbox, and it asks for a password reset, a payment, or a favor. Your users have no way to tell it is not you. Neither does theirs.

There is a second, quieter cost. When your domain has no authentication records, your legitimate mail — the password resets, the receipts — looks statistically similar to the spoofed kind. Deliverability suffers over time. You end up in a fight you did not choose.

What the three records do

DNS is where you tell the world which senders and certificate authorities are allowed to speak for your domain. Three record types matter for this finding:

SPF — which servers may send your mail

A TXT record on the domain that lists the services allowed to send email on its behalf. Without it, there is nothing to check against, so receivers fall back to trusting the message at face value.

DMARC — what to do when SPF and DKIM disagree

A TXT record at _dmarc.yourdomain.com that tells receivers how to handle mail that claims to be from you but fails the checks: take no action, quarantine, or reject. It also gives you a reporting address so you can see who is sending as you. SPF without DMARC is a suggestion. DMARC is the policy.

CAA — who may issue certificates for you

A record that names the certificate authorities allowed to issue TLS certificates for your domain. Without it, any CA in the world can be tricked or pressured into issuing a certificate for your hostname, and browsers will trust it. This one is technically separate from email, but it lives in the same family: unclaimed DNS claims that someone else can make for you.

The fix, in the right order

The order matters because doing DMARC wrong can silently drop real mail. Work through it in this sequence and check after each step.

Step 1: inventory your senders

Before writing any record, know what actually sends mail as your domain. Your transactional provider (Resend, SendGrid, Postmark, Mailgun), your Google Workspace or Microsoft 365 tenant, any marketing tool, any support tool. Miss one and the first strict policy will bounce your own receipts.

Step 2: add SPF

One TXT record on the root domain. Only one is allowed; if one already exists, merge rather than add a second. A typical version looks like this:

yourdomain.com  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

# one record only. if something already sits here, edit it.
# ~all means "soft fail" — mark it, don't reject yet.
# move to -all once you are sure the list is complete.

Step 3: add DMARC in monitor mode first

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

p=none means: collect reports, take no action against failing mail. Let it run for a week or two and read the reports. You are looking for legitimate senders you missed. When the reports are boring, tighten the policy to p=quarantine, wait, then p=reject. Reject is the goal. Being at p=none forever is the finding, just wearing a badge.

Step 4: add CAA

yourdomain.com  CAA  0 issue "letsencrypt.org"
yourdomain.com  CAA  0 issuewild "letsencrypt.org"
yourdomain.com  CAA  0 iodef "mailto:security@yourdomain.com"

# list every CA you actually use. If you use a managed host that
# issues through its own CA, name that one too.

How to verify it, without breaking your email

Two lookups and one real email:

dig TXT yourdomain.com +short | grep spf
dig TXT _dmarc.yourdomain.com +short
dig CAA yourdomain.com +short

# then send a real test email through each legitimate sender
# (password reset, receipt, support reply) and confirm delivery.

DNS changes can take a little while to appear, and some resolvers cache longer than others. If a lookup looks empty right after you save the record, wait ten minutes and try again before assuming you got it wrong.

How this drifts back

You add a new email tool six months from now, it asks for DNS records, you add its include to SPF. That part is normal. The drift that actually bites is smaller: a second SPF record gets created instead of editing the first one (receivers treat multiple records as invalid, and you have quietly turned SPF off), or DMARC stays at p=none forever because enforcement felt risky, or a subdomain starts sending mail and was never covered.

The version of this mistake we see most: everything is added correctly by a thoughtful engineer, then the domain moves to a different DNS host during a migration and the records are not copied over. The new host is happy to serve the zone. The records are just gone. Nobody notices because email still works — for everyone sending as you.

An honest limit

DNS records reduce spoofing; they do not end it. Attackers can lookalike your domain (yourdomain.co, your-domain.com) and no record you publish changes that. What these records do is remove the free win: the exact-domain forgery that lands in the normal inbox. That is worth an afternoon.

Also, DKIM is the other half of email authentication. Your sending provider usually signs with a DKIM key when you add the domain there, and it is configured on the provider side, not yours. If you have set up a transactional provider, you probably already have DKIM without thinking about it. The finding you get from us is about the records you own: SPF, DMARC, and CAA.

You can still ship this fix yourself. With GitHub connected, Zoltra can also prepare the repair as a pull request when the fix lives in code, and verify the live result after deployment. For DNS, the fix is at your registrar, and no code needs to change.

Related: Missing security headers and How to read your report.