Mosfetti Forum

When mail lands in spam—or never arrives—the fix is rarely “delete and recreate the mailbox again.” Delivery depends on who is allowed to send for your domain (SPF), whether the message is cryptographically aligned (DKIM), and where receivers should accept mail (MX). This article explains those three DNS pieces in plain language and a setup order that avoids breaking a working site.

Separate “website host” from “mail host”

Your website can live on Server A while mail lives on Google Workspace, Microsoft 365, Fastmail, or a different mail server. DNS is the map:

Need — Record type (typical)
Where to **deliver** inbound mail — `MX`
Which servers may **send** for the domain — `TXT` SPF
Cryptographic signature verification — `TXT` DKIM (`selector._domainkey`)
Policy for failed checks (optional later) — `TXT` DMARC (`_dmarc`)

Changing the website [font=monospace]A[/font] record does not require changing [font=monospace]MX[/font] unless you intentionally move mail.

MX records — inbound delivery

• MX points to a hostname, not usually a raw IP (e.g. [font=monospace]mail.example.com[/font] or provider hosts like [font=monospace]smtp.google.com[/font] patterns per provider docs).
• Priority numbers: lower number = higher priority. Keep the set exactly as the provider documents.
• Multiple MX values are normal for provider redundancy—do not invent extras.

Check:
[font=monospace]dig MX example.com +short[/font]
Compare to your provider’s setup guide.

SPF — authorization to send

SPF is a DNS [font=monospace]TXT[/font] record on the apex (or the exact domain that appears in the envelope sender). Example shape (illustrative—not copy-paste for every host):
Rules of thumb:

1. One SPF TXT per domain name (merge mechanisms; do not create two competing [font=monospace]v=spf1[/font] records).
2. Prefer [font=monospace]include:[/font] mechanisms from your real senders (ESP, Google, Microsoft, transactional mail).
3. Every marketing tool that sends as [font=monospace]@yourdomain[/font] must be represented or mail will fail alignment.
4. Soft fail [font=monospace]~all[/font] vs hard fail [font=monospace]-all[/font]: harden only after you know all senders.

Check:
[font=monospace]dig TXT example.com +short[/font] and look for [font=monospace]v=spf1[/font].

DKIM — message signing

Your mail platform generates a public key published at a selector name:
You enable signing in the mail admin UI so outbound messages carry a DKIM signature header. Receivers fetch the DNS key and verify.

If DKIM is “enabled” in the panel but the DNS TXT is missing or truncated (common with long keys split wrong), signatures fail.

DMARC — policy layer (after SPF/DKIM work)

Start carefully:
[font=monospace]p=none[/font] monitors. Move to [font=monospace]quarantine[/font] or [font=monospace]reject[/font] only when reports show legitimate mail passes.

A practical setup order for a new business domain

1. Create mailboxes at the chosen provider.
2. Publish MX as documented; wait for DNS TTL.
3. Publish SPF including that provider (and only known senders).
4. Publish DKIM keys; send a test to an external inbox; inspect headers for [font=monospace]dkim=pass[/font].
5. Add DMARC at [font=monospace]p=none[/font].
6. Only then connect website forms / billing mail / CRM senders and update SPF includes.

Testing without folklore

• Send to a mailbox you control on a different provider (e.g. personal Gmail if business is not Gmail).
• Read full headers: look for [font=monospace]Received-SPF[/font], [font=monospace]Authentication-Results[/font] ([font=monospace]spf=[/font], [font=monospace]dkim=[/font], [font=monospace]dmarc=[/font]).
• Online “score” tools can help spot missing records but can also scare you with unrelated TLS or list-unsubscribe nits—prioritize SPF/DKIM/DMARC alignment for your From: domain.

Website forms and “server PHP mail”

Many contact forms use the web server’s PHP [font=monospace]mail()[/font] with no authentication. Receivers increasingly distrust that path. Prefer:

• Authenticated SMTP to your provider, or
• A transactional API (with its SPF/DKIM includes)

Otherwise form mail may never show SPF pass for your domain.

What not to do

• Do not delete all TXT records “to start clean” (you may remove verification or site records).
• Do not point MX to your web host “temporarily” if mailboxes are not there.
• Do not copy another company’s SPF [font=monospace]include:[/font] list.
• Do not publish DMARC [font=monospace]p=reject[/font] on day one of a migration.

Conclusion

Reliable business email is DNS plus authenticated sending—not a mysterious inbox lottery. Keep web and mail changes separate, publish MX/SPF/DKIM in a deliberate order, and verify with real message headers before tightening DMARC.