Inventory senders and the active DNS provider first. Configure provider-specific authentication, verify real messages and monitor before tightening DMARC. Authentication is not an inbox-placement guarantee.
Start with a list of every service that sends email as your business. Then configure SPF and DKIM using those services’ exact instructions, verify real messages, and introduce DMARC with monitoring before stricter enforcement. Do not begin by pasting a restrictive DNS record from another company’s tutorial.
A business can have more senders than mailboxes: a newsletter tool, a website form, a store sending receipts, a help desk and an invoicing application. One unrecorded sender can explain why everyday messages work while customer notifications fail. This guide is researched documentation and an original planning worksheet; we did not change a live domain or measure delivery.
What the three names mean
| Method | Question it helps answer | It does not prove |
|---|---|---|
| SPF | Is this sending server authorized for the checked envelope domain? | That the visible From address alone is authenticated |
| DKIM | Does this signed message verify with the signing domain’s public key? | That the message is wanted or harmless |
| DMARC | Does an authenticated SPF or DKIM domain align with the visible From domain? | That every receiver must put the message in an inbox |
These are simplified explanations of SPF, DKIM and DMARC. They help authenticate sending identity. They do not replace account security, consent, good content or responsible sending.
The current DMARC specification is RFC 9989, published in May 2026. Aggregate and failure reporting are specified separately in RFC 9990 and RFC 9991. Check the receiving provider’s current requirements; publication does not mean every receiver implements a standard identically.
1. Make a sender inventory
| Mail stream | Who sends it? | What to record | Verification sample |
|---|---|---|---|
| Staff messages | Mailbox provider | From domain, account owner, SPF instructions, DKIM selector | A staff message and a reply |
| Website enquiries | Form transport or sending service | Authenticated From, visitor Reply-To, sending route | A real form submission |
| Store receipts | Store or transactional provider | Order sender, domain/subdomain, signing setup | A permitted test order notice |
| Newsletter | Marketing platform | Sending domain, verification status, unsubscribe behavior | A test to an owned address |
| Invoices and support | Billing/help-desk applications | Each service’s own instructions and owner | A representative notification |
Ask colleagues about less frequent messages, such as annual renewals and password resets. Write down who can approve DNS changes and who can contact each service. Inventory the active authoritative DNS zone, not merely the registrar’s account page. Preserve current records before editing.
2. Check SPF without creating a second competing policy
SPF checks the envelope or HELO identity, not simply the address a person sees. RFC 7208 prohibits multiple selected SPF records at the same name. A new provider’s instructions therefore need reconciling with any existing policy for that name. Do not delete the current mailbox provider just to satisfy the new newsletter wizard.
Ask the providers or a qualified administrator to validate the combined policy and its DNS lookup limits, including nested dependencies. Do not authorize every server as a shortcut. Record which stream uses which envelope domain; a provider may use its own return-path or a dedicated subdomain. The correct values depend on that actual arrangement.
3. Enable each service’s DKIM signing
DKIM uses a signing key and a public DNS record associated with a selector. Different services can use different selectors. Follow the account’s exact record type, name and value, then complete any required signing activation inside the sending service. Publishing a record and enabling signing can be separate steps.
MailerLite provides account-specific authentication and verification records. Its example workflow does not supply your mailbox provider’s records. Keep private keys and account secrets private; public DNS verification values are a different category. Retain the service’s confirmed configuration in your internal inventory.
4. Monitor DMARC before tightening the policy
DMARC needs an aligned SPF or DKIM pass: a pass for an unrelated provider domain is not enough by itself. A monitoring policy can collect evidence without asking for DMARC quarantine or rejection. It does not disable the recipient’s other spam filters or prove that spoofing is blocked.
Google recommends a gradual rollout with report review before enforcement. Choose a reporting destination you control, protect report data and investigate unexplained senders. Observe the business’s actual cycle, including occasional receipts or billing runs. A week with no complaint is not proof that a monthly sender is covered.
Only tighten the policy after legitimate streams pass and an accountable person can investigate failures and restore the previous configuration. There is no universal DNS string in this guide because the sender inventory, subdomain policy and report destination differ by business.
Gmail’s general and bulk requirements differ
Google’s personal Gmail guidelines distinguish all senders from bulk senders. The general requirement includes SPF or DKIM; the bulk requirements include SPF, DKIM and DMARC, with alignment and additional subscribed-message rules. Read the current threshold and scope rather than assuming a small team is exempt from all authentication work or automatically subject to every bulk rule.
Verify each stream, then decide whether to buy anything
- Send an authorized representative sample from every recorded service.
- Inspect the recipient’s original-message authentication results and domains, not just a green provider dashboard.
- Check incoming replies and form notifications separately.
- Review reports and rejection messages; investigate before changing multiple records.
- Keep the inventory current whenever a new application sends as your business.
A correct DNS setup may solve the problem without a new subscription. Buy a mailbox, marketing or transactional service only when its role and limits fit. Read mailbox versus marketing email and the WordPress form diagnosis to avoid buying the wrong category. Authentication is necessary work, not a promise of inbox placement.
Sources and verification
Editorial review 2026-10-09. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Google Gmail sender guidelinesChecked Personal Gmail has separate general and bulk sender requirements, including authentication and alignment, plus reputation and unsubscribe requirements.
Limits: Recipient-specific policy, not a universal statement that every small sender is a bulk sender. Authentication does not guarantee inbox placement. - SPF protocol, RFC 7208Checked SPF authorizes hosts for MAIL FROM/HELO identities; multiple selected SPF records cause an error; DNS lookup limits apply.
Limits: A protocol reference does not supply the exact authorized hosts or policy for a real business. - DKIM signatures, RFC 6376Checked DKIM signs message content using a domain-associated key; selectors locate the public key in DNS.
Limits: A valid signature does not establish message desirability or guarantee delivery. Later receiver and cryptographic requirements must also be respected. - DMARC protocol, RFC 9989Checked Current DMARC specification: identifier alignment and domain policy discovery.
Limits: Publication in May 2026 does not establish universal receiver adoption; check current provider requirements separately. - DMARC aggregate reporting, RFC 9990Checked Current DMARC aggregate reporting specification.
Limits: Report availability and implementation depend on participating receivers. - DMARC failure reporting, RFC 9991Checked Current DMARC failure reporting specification.
Limits: Failure reports are distinct from aggregate reports, can contain sensitive information and are not guaranteed. - MailerLite domain authenticationChecked MailerLite provides exact DKIM, SPF and verification values and checks DNS matches.
Limits: Provider-specific record names and values must come from the actual account; no authentication or campaign was performed. - Google recommended DMARC rolloutChecked Google recommends monitoring first and moving gradually to enforcement after reviewing legitimate sending streams.
Limits: Public search-rendered documentation was available, but a full-page browser-tool fetch failed. Its sample timing is guidance, not a guarantee that all business senders have been observed.