Receiving vs sending
Grade school
One set of records tells the world where to deliver mail to you. Other records say who may send mail as you. Adding a sending service only touches the second kind.
High school
MX records say which company receives your email — your inbox provider. SPF, DKIM and DMARC say who’s allowed to send as your domain. Setting up SendGrid, Brevo or another sending service never means changing your MX records.
College
MX routes inbound SMTP to your mailbox provider. Outbound authentication is independent: SPF authorizes sending hosts for the envelope (return-path) domain, DKIM signs messages, and DMARC ties both to the visible From domain. A transactional provider needs outbound records only.
Postgraduate
Separate inbound and outbound concerns in both configuration and change control. Editing MX during a sending-provider change risks losing inbound mail, a failure mode unrelated to the goal. Some providers use their own MX on a return-path subdomain for bounce processing; that is scoped to the subdomain and doesn’t affect your apex MX.
Developer
Apex/root MX → mailbox provider (e.g. Google Workspace or Microsoft 365). A provider bounce domain such as em[NNNN].brand.example may carry its own MX/SPF (SendGrid with automated security off) or be delegated wholesale by CNAME (automated security on). Don’t touch apex MX.
SPF
Grade school
SPF is a list of who’s allowed to send mail for your domain. You can only have one list, so if you need to add someone, you add them to the same list.
High school
SPF is a single TXT record that lists the services allowed to send as your domain, for example your mailbox provider. A domain can have only one SPF record — two records break both.
Many sending services don’t need you to change it at all. SendGrid, for example, handles SPF on its own subdomain. If your service does ask for an SPF addition, add its include: to your existing record instead of creating a new one.
College
SPF (RFC 7208) is checked against the envelope sender (return-path) domain, not the From header. Each host can publish one SPF record. Evaluating it may use at most 10 DNS-querying terms (include, a, mx, exists, redirect, including nested includes); going over causes a permanent error.
That’s why providers such as SendGrid use a custom return-path subdomain: SPF passes there without adding lookups to your root record.
Postgraduate
SPF authenticates the SMTP MAIL FROM identity. On its own it doesn’t protect the From address customers see; DMARC supplies that link through alignment. The 10-lookup budget is a shared, finite resource across every service at the root, so subdomain delegation is the scalable pattern. Avoid flattening includes for providers with changing IP ranges, Microsoft 365 among them.
Developer
Merge, don’t duplicate: v=spf1 include:_spf.google.com include:[provider-include] ~all — one TXT per host. Count lookups recursively. Where a provider uses a CNAME’d return-path (em[NNNN]), no apex change is needed. Microsoft 365 uses include:spf.protection.outlook.com. Verify with dig +short TXT brand.example against each authoritative nameserver.
DKIM
Grade school
DKIM is like a wax seal on a letter. It shows the email really came from your store and wasn’t changed on the way.
High school
DKIM adds a digital signature to each email. Your sending service gives you one or more DKIM records to add. Each service uses its own record names, so several services can each have their own DKIM at the same time without clashing.
College
The provider signs each message with a private key; receivers fetch the public key from DNS at selector._domainkey.brand.example. Selectors are provider-specific — SendGrid commonly uses s1/s2 by CNAME, Brevo shows its own DKIM host. Keep other services’ selectors, including your mailbox provider’s.
Postgraduate
DKIM survives forwarding better than SPF, which makes it the more robust basis for DMARC alignment. CNAME-delegated selectors let the provider rotate keys without DNS changes; TXT-published keys require you to update DNS on rotation. The signing domain (d=) must match or align with the From domain for DMARC to pass on DKIM.
Developer
Check DKIM-Signature: d=brand.example; s=s1 in received headers and dkim=pass header.d=brand.example in Authentication-Results. Resolve dig CNAME s1._domainkey.brand.example. Unique selectors per provider avoid collisions during migrations.
DMARC
Grade school
DMARC tells other email systems what to do if someone pretends to be you. Keep the one you already have — don’t make it weaker.
High school
DMARC is one TXT record at _dmarc.brand.example. It asks receiving mail servers to check that SPF or DKIM passed for your domain, and says what to do if not: nothing (p=none), send to spam (quarantine) or reject.
If you already have DMARC, keep it. Some services offer to replace it with a basic p=none record — say no and add their other records yourself.
College
DMARC requires alignment: the From domain must match the SPF-authenticated or DKIM-signing domain (relaxed alignment allows subdomains). Roll out in stages: start at p=none with aggregate reports (rua), fix every legitimate sender, then move to quarantine and reject.
Gmail requires DMARC and alignment for bulk senders (5,000+ messages a day to Gmail); every sender needs SPF or DKIM.
Postgraduate
DMARC turns separate authentication results into a policy about the identity customers see. Relaxing an enforcing policy to clear one provider’s failure lowers spoofing protection for the whole domain. The right fix is to make that sender align: authenticate its DKIM on your domain, or its return-path on a subdomain. Aggregate reports show what actually sends as you before you tighten.
Developer
_dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:dmarc@brand.example; adkim=r; aspf=r" as a starting point only if none exists. Only one DMARC record per host. Check dmarc=pass header.from=brand.example in received headers. Progress p= and pct= on evidence from reports.
Shared and dedicated sending IPs
Grade school
Most small stores share sending computers with other good senders. That’s normal and fine.
High school
By default your sending service sends from shared IP addresses used by many customers. Most storefronts never need anything else. A dedicated IP is one only you use; it’s usually offered on higher plans and only makes sense at high, steady volume. It isn’t required for YPB storefronts.
College
Reputation attaches to both the sending domain and the sending IP. On shared pools the provider manages IP reputation. A dedicated IP gives you full control — and full responsibility: it needs consistent volume and a gradual warmup (increasing daily sends over weeks) before it performs well. Low-volume senders often do worse on a dedicated IP than on a well-run shared pool.
Postgraduate
Dedicated IPs isolate you from neighbours’ behaviour but remove the smoothing a shared pool provides. Mailbox providers score recent volume and engagement, so irregular transactional volume can leave a dedicated IP “cold”. Domain-based reputation (DKIM d=) now carries much of the signal, which reduces the benefit of IP isolation for small senders.
Developer
Evaluate the provider’s dedicated-IP thresholds and warmup schedule (for example SendGrid IP warmup). Keep transactional and marketing streams on separate IPs or subdomains where volume justifies it. Monitor Google Postmaster Tools for domain and IP reputation.
Reverse DNS (PTR)
Grade school
Reverse DNS is a label on the sending computer. The company that owns that computer sets it, not you.
High school
A PTR record links an IP address back to a name. For shared IPs, your sending service already handles it. With a dedicated IP, the provider sets the PTR and may ask you to add one matching record to your domain. It has nothing to do with your website’s hosting address.
College
PTR records live in the reverse DNS zone controlled by whoever owns the IP block — your sending provider, not your DNS host. Receivers check that the PTR name resolves forward to the same IP (forward-confirmed reverse DNS). For a dedicated IP, SendGrid’s reverse-DNS setup has you add a forward A record at a name on your domain; the provider publishes the PTR.
Postgraduate
Valid forward and reverse DNS is part of Gmail’s baseline sender requirements, but it is a property of the sending infrastructure. Customers can’t create PTRs in their own zone for IPs they don’t control, and the website’s hosting IP has no role in transactional mail sent through a provider.
Developer
Check with dig -x [sending-IP], then resolve the returned name forward. For SendGrid dedicated IPs see reverse DNS setup: you add the forward A record exactly as SendGrid shows it; SendGrid manages the PTR.