Skip to content

Product

Common Mail Configuration mistakes that still ship

Shipping with abandoned MX hosts, SPF kitchensink includes, and eternal DMARC p=none still happens—Mail configuration mistakes that show up in public DNS first.

· by Sam Ortega

Common Mail Configuration mistakes that still ship

Ops teams inherit DNS folklore. The mistakes that still ship treat public mail records as set-and-forget. SlaySlop's Mail configuration check "Checks public mail-routing and sender-policy records." If those records still name ghosts, you shipped ghosts.

Outcome if you catch these early

Public routing and sender policy match living vendors. Lookups stay within usable SPF limits. DMARC has an owner and a trajectory. DNS records and DNSSEC are not ignored as "not mail."

Boundaries

Read-only public DNS. Permissioned. Not a pentest. Not inbox testing. Mail configuration lives under Domain and infrastructure with DNS records, DNSSEC, WHOIS, redirects, ports, and related signals.

Loading diagram.

Mistake 1: MX left on a cancelled host

The site moved. Mail records did not. Users mail info@ into a black hole. Dig tells on you.

bash
dig example.com MX +short

Mistake 2: SPF includes every vendor forever

Each campaign adds an include:. Eventually you exceed practical lookup limits or authorize senders nobody monitors. Trim to living systems.

text
mistake: spf_kitchen_sink
symptom: TXT SPF lists departed ESPs
fix: inventory senders; remove dead includes; re-check public TXT

Mistake 3: no DMARC, or p=none with no plan

p=none can be a deliberate monitor phase. Eternal p=none with unread rua mailboxes is cosplay. Missing DMARC is worse. Public policy records are part of what Mail configuration is for.

bash
dig _dmarc.example.com TXT +short

Mistake 4: "static site" excuse

Brochure sites still receive and send mail more often than decks admit. Saying you have no mail does not erase MX and SPF that still publish.

Mistake 5: fixing apex, forgetting send subdomains

news.example.com or mail.example.com may be the real sending identity. Check the domains that appear in From headers, not only the website apex.

Mistake 6: treating DNS records inventory as done mail work

DNS records collect public configuration broadly. Mail configuration focuses mail-routing and sender-policy. Read both; close neither with superstition.

Mistake 7: no permissioned review on client domains

Agencies sometimes "just dig" a prospect and paste advice. Keep Acceptable Use and contracts in mind. Public data still deserves professional boundaries.

Loading diagram.

More context

After migrations, schedule a rescan. Domain insights copy notes that future scans reveal when public configuration shifts. That line exists because drifts are normal and quiet.

Expansion

Mistake 8: editing policy in the wrong DNS host

CDN UI, registrar DNS, and ESP instructions disagree about where the zone lives. You publish SPF in the wrong panel and public DNS never changes. Dig against a public resolver before declaring victory.

bash
dig @8.8.8.8 example.com TXT +short
dig example.com NS +short

If NS still delegates to a previous DNS host, you edited a ghost. DNS records collection makes that visible; Mail configuration then reads whatever public policy actually exists.

Agency ops note

Put "mail records" on the same checklist as favicon and 404 design. It is less glamorous and more likely to page someone at 11pm when a spoof goes viral on social. False calm is expensive.

Related next step

Put Mail configuration on the launch checklist beside DNS records. SlaySlop surfaces those public signals in one domain view.