Which Email DNS Fixes Can Be Automatic (and Why Some Can't)
See which email DNS fixes Domain Email Doctor can apply for you, which ones need your input, and the reason behind each, from SPF and DMARC to DKIM and MTA-STS.
After a scan, some fixes show a "Fix this for me" button while others only show you the exact records to add yourself. That is deliberate. We auto-apply a change only when it is safe and unambiguous, and we guide you by hand for everything that needs your judgment or a value only your provider can give you.
Two questions decide whether a fix can be automatic. First: can we reach the place your DNS is managed? Second: even if we can, is the change safe to make without your input? This guide walks through both, so the result page never feels arbitrary.
Check your domain now, then use this guide to understand the result.
Check my domain - freeOn this page
Question 1: Can we reach your DNS host?
Writing a DNS record always needs the cooperation of whoever hosts your DNS. There is no way around that, so the first thing that decides auto-fix is where your domain's nameservers point.
| Where your DNS is hosted | What you get |
|---|---|
| Cloudflare, Porkbun, DigitalOcean, Vercel, deSEC, or AWS Route 53 | "Fix this for me" is available for eligible exact changes. You approve each change; we never see your password or delete records. Credential access differs by host: Cloudflare: select only this zone and grant both Zone DNS Edit and Zone Read. DNS Edit can create, change, or delete records in the zone, although this connector never deletes records. Porkbun: restrict the key's exact target-domain allowlist to this domain and enable API Access on the domain. The key is still not DNS-only and can perform other Porkbun API operations for the allowed domain; this connector never deletes records. DigitalOcean: create a custom-scoped token with domain:read, domain:create, and domain:update. Those actions cover every managed domain in the team, but not deletion or non-domain resources. Vercel: this is not a DNS-only token; it grants broad API access within the selected Personal Account or Team, subject to your Vercel role. This connector omits the teamId Vercel requires for Team resources, so use Personal Account scope here. deSEC: use a default-deny RRset policy that permits writes only for this domain, with domain create/delete and token-management disabled. All deSEC tokens can still read every RRset across every domain in the account. AWS Route 53: create a dedicated IAM user, never root or admin. Attach the explicit two-statement policy shown in setup: discovery on Resource '*', then record reads and UPSERT-only writes on arn:aws:route53:::hostedzone/<ZONE_ID>. Replace <ZONE_ID> with the target hosted-zone ID; never broaden that ARN to '*'. Keep writes restricted to MX, TXT, and CNAME. |
| GoDaddy and similar hosts | We show you the exact records to paste, with host-specific steps, usually about two minutes. Domain Email Doctor does not currently offer Domain Connect apply. |
| We could not tell | The fix wizard helps you find where your DNS is managed, then shows the exact records for that host. |
Changing DNS hosts is optional and does not make every finding automatic. If you are considering it, Move your DNS to Cloudflare explains how to copy records safely and which changes remain eligible: known-provider MX records and tightening an existing SPF record's terminal qualifier.
Question 2: Is the fix safe to apply without your input?
Reaching your host is only half of it. Some changes are safe to make from a template; others can quietly break your mail or simply cannot be guessed. Here is every fix, grouped by the reason it is automatic or not.
| Fix | How we handle it | Why |
|---|---|---|
| known-provider MX records and tightening an existing SPF record's terminal qualifier | Auto-fix | The value is a provider-published constant or a transformation of your domain's own existing record. SPF tightening preserves every sender already listed. |
| Publishing a first SPF record | Review and copy manually | Inbound MX identifies who receives mail, not every system that sends it. Inventory mailbox, marketing, transactional, CRM, helpdesk, billing, and self-hosted senders before publishing; an incomplete record ending in -all can reject legitimate mail. |
| Publishing a first DMARC record | Review and copy manually | A useful p=none policy needs a real reporting mailbox in rua. We show a starter value, but never auto-write an invented mailbox or imply that monitoring works before you create and monitor it. |
| Raising your DMARC policy from p=none to quarantine or reject | Guided | This is the single biggest deliverability lever, but doing it before SPF and DKIM are aligned can send legitimate mail to junk. We explain it and let you decide. |
| DMARC and TLS-RPT reporting addresses | You provide the destination | Reports have to go somewhere you control. We cannot invent a mailbox or a reporting service for you. |
| MTA-STS | Advisory only | The DNS record is easy, but MTA-STS also needs a policy file hosted at a special URL on your domain. Publishing only the DNS half creates a broken policy, which is worse than not having it. |
| DKIM keys, a BIMI logo, or Google and Microsoft verification tokens | Copy from your provider | These are generated by your email or brand provider and are unique to you. There is nothing for us to invent. |
| Merging, repairing, or flattening an existing SPF record | Your judgment | Deciding which senders are real and which to drop is a human call. Automatic rewriting can silently omit a legitimate sender and stop that sender's mail. Separately, flatten provider IPs only if you can keep them safely updated; stale IPs can silently break mail. |
| A separately confirmed no-mail domain | Fixed no-mail records can be automatic | A separately confirmed no-mail lockdown can apply fixed RFC no-mail records. |
What this means on your results page
Every fixable finding on your report follows the same rule:
- When a fix is safe and your host is reachable, you get "Fix this for me" next to "I'll fix it myself".
- When a fix is safe but your host is manual, you get the exact records to paste and host-specific steps.
- When a fix needs your judgment or a provider value, we explain what to do and link the relevant guide instead of a one-click button.
None of this changes what your scan reports. It only changes how the fix is delivered: the records and explanations are the same whether you apply them yourself or let us do it.
For the background on the records themselves, see SPF vs DKIM vs DMARC and the DMARC record checker.
Quick checklist
- Auto-fixed for ordinary email-setup findings when safe and your host is reachable: known-provider MX records and tightening an existing SPF record's terminal qualifier.
- A separately confirmed no-mail lockdown can apply fixed RFC no-mail records.
- Review and copy manually: a first SPF after inventorying every sender, and a first DMARC after choosing a real monitored reporting mailbox.
- Guided, never automatic: raising DMARC to quarantine or reject - confirm SPF and DKIM align first.
- You provide: DMARC and TLS-RPT reporting addresses, a destination only you choose.
- Advisory only: MTA-STS, because it also needs a hosted policy file, not just a DNS record.
- Copy from your provider: DKIM keys, BIMI logos, and verification tokens, which we cannot invent.