DNS for email and your storefront

Grade school

SPF is a list on your domain of the services allowed to send your email. If a stranger tries to pretend to be you, the list says “not allowed”.

High school

SPF is one TXT record starting v=spf1 that lists who may send email for your domain. Each sending provider tells you what to add. You must have only one SPF record, so new providers are added into the existing record, not as a second one.

College

Receiving servers check SPF against the envelope sender (return path), not the From address people see. That’s why SendGrid publishes SPF on its own return-path subdomain (em[NNNN]) and doesn’t need your main SPF record changed, while Google Workspace and Microsoft 365 ask you to add an include: to it. SPF evaluation stops after 10 DNS lookups, so a record with too many includes fails.

Postgraduate

SPF authorizes infrastructure, not identity: it binds a domain to permitted sending hosts for the SMTP MAIL FROM. It breaks under forwarding and says nothing about the visible From, which is why DMARC requires alignment. Governance-wise, every include: delegates trust to a third party’s address space; prune obsolete providers and treat the 10-lookup budget as a hard constraint.

Developer

RFC 7208: a name MUST NOT publish multiple SPF records (§3.2); evaluation MUST stop after 10 DNS-querying terms — include, a, mx, ptr, exists, redirect — and SHOULD allow at most two void lookups (§4.6.4). Example merged record:

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Check with dig +short TXT example.com. Avoid ptr; flatten only with tooling that tracks upstream changes.

Grade school

DKIM is like a wax seal on a letter. Your provider seals every email, and other computers check the seal against a key on your domain.

High school

DKIM adds a digital signature to each message. Your provider gives you one or more records (a TXT or CNAME at a name ending ._domainkey) that hold the key to check it. Each provider has its own, so several can live side by side.

College

The provider signs with a private key and publishes the public key at <selector>._domainkey.example.com. Selectors let multiple providers and key rotations coexist. SendGrid and Microsoft 365 use CNAMEs to their own hosted keys so they can rotate them; Google uses a TXT record with the key itself, and Brevo’s DKIM record is a TXT or CNAME as shown in your account.

Postgraduate

DKIM binds a domain (d=) to message content, survives forwarding better than SPF, and is the stronger basis for DMARC alignment. CNAME-delegated keys shift rotation duty to the provider; TXT-published keys make rotation your responsibility. Retire a provider’s selector only after it has stopped signing.

Developer

Verify with dig +short TXT s1._domainkey.example.com (follow CNAMEs) and in a received message’s DKIM-Signature: d=example.com; s=s1. SendGrid rotates signing between s1 and s2; Microsoft between selector1 and selector2. Use 2048-bit keys where the provider offers them.

Grade school

DMARC is your rule for what to do with fake emails that pretend to be you. Start by just watching, then later ask other computers to block the fakes.

High school

DMARC is one TXT record at _dmarc.example.com. It checks that SPF or DKIM passed for the same domain as the From address, and tells receivers what to do if not: p=none (watch), quarantine or reject. If you already have a DMARC record, keep it — don’t add a second one or replace it with a weaker one.

College

DMARC passes when SPF or DKIM passes and aligns with the visible From domain. Roll it out in stages: start at p=none with an rua= reporting address, fix every legitimate sender that fails, then move to quarantine and reject. Gmail and Yahoo require DMARC for bulk senders.

Postgraduate

DMARC turns authentication into published policy and a reporting loop. Aggregate reports reveal every source claiming your domain, including forgotten tools, which makes the rollout an inventory exercise as much as a DNS change. Weakening an existing policy to make one sender pass trades domain-wide protection for local convenience; fix alignment at the sender instead.

Developer

RFC 7489: identifier alignment is relaxed by default (adkim=r; aspf=r, organizational-domain match). Example staged record:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Check a real message’s Authentication-Results: dmarc=pass header.from=example.com. Only one DMARC record may exist at _dmarc.

Grade school

Every email provider asks for different notes. Copy exactly what your provider shows you, for your own domain.

High school

The records below show each provider’s pattern. The exact values are generated for your domain inside your provider account — never copy them from another business or from this page.

College

Providers differ in record type (CNAME versus TXT) and in whether they touch your main SPF record. The table shows the pattern; your provider’s screen shows the values.

Postgraduate

Record shapes encode who controls rotation and authorization: CNAME delegation keeps key management with the provider; TXT and SPF includes keep it with you. Choose knowing which party you’re trusting.

Developer

Values are per account and domain. Validate each record against every authoritative nameserver (dig @ns1.example-dns.net …) before asking the provider to verify.

Grade school

Most stores share a mail truck with other senders, and that’s fine. Very big senders can get their own truck, but they have to drive it carefully at first.

High school

Most providers send your mail from shared IP addresses they look after. A dedicated IP is your own, and only makes sense if you send a lot of email regularly. A new dedicated IP must be “warmed up” by sending slowly at first.

College

Reputation attaches to both your domain and the sending IP. On shared pools the provider manages IP reputation, and low-volume stores benefit from it; SendGrid says Free and Essentials plans use shared pools and need no warm-up. A dedicated IP isolates you from other senders but needs consistent volume and a gradual warm-up.

Postgraduate

A dedicated IP converts reputation from a pooled good into a private one: you gain isolation and accountability but lose the provider’s averaging. Low or bursty transactional volume often performs worse on a cold dedicated IP. Decide on measured volume and provider guidance, not as a default.

Developer

SendGrid recommends warming a new dedicated IP by increasing volume gradually and re-warming after 30 or more days idle; its automated warm-up runs over about 41 days. Monitor bounces, blocks and spam reports per IP during warm-up.

Grade school

Reverse DNS lets someone look up a sending address and see a name. Whoever owns the sending address sets it up, not you.

High school

A PTR record maps an IP address back to a name. It is set by whoever owns the sending IP — your email provider — not in your domain’s normal DNS. On shared IPs the provider handles it. It has nothing to do with your website’s IP.

College

PTR lives in the reverse zone controlled by the IP owner. With a SendGrid dedicated IP, SendGrid manages the PTR and you add a forward A record it generates so the names match (forward-confirmed reverse DNS). You can’t set a PTR for your provider’s IP from your own DNS host.

Postgraduate

Receivers use forward-confirmed reverse DNS as a hygiene signal about the sending infrastructure, so it belongs with whoever operates that infrastructure. Don’t confuse it with the storefront’s hosting IP, which is a separate system.

Developer

SendGrid reverse DNS requires a dedicated IP; you publish the generated A record (for example o1.em[NNNN].example.com → <dedicated IP>) and SendGrid publishes the PTR. Check with dig -x <ip> then resolve the returned name forward.

Grade school

MX records tell the world where to deliver mail to you. Sending services don’t change them.

High school

MX records point to your mailbox provider, such as Google Workspace or Microsoft 365. Setting up SendGrid, Brevo or another sending service never changes them. Replies to your store reach you through MX.

College

Receiving (MX) and sending (SPF/DKIM/DMARC) are independent. A transactional provider sends only; replies follow the Reply-To address to the mailbox that your MX records point to.

Postgraduate

Keeping receiving separate from sending avoids coupling your inbox’s availability to a sending vendor. A change to MX is a mailbox migration and needs its own plan.

Developer

Confirm with dig +short MX example.com. Provider-owned subdomain MX records (for example SendGrid’s return-path MX when automated security is off) don’t affect the apex MX.

Grade school

Your website’s address needs a note that says which computer shows your store. YPB tells you what to write.

High school

To point your domain at your YPB storefront, you change only the web records — usually an A record for example.com and a record for www.example.com. Everything else, including your email records, stays. YPB gives you your exact values privately.

College

Your storefront is hosted on Hostinger. Pointing records (A/AAAA for the apex, A or CNAME for www) moves web traffic without touching mail. Each environment has its own hostname. DNS only resolves names; the redirect from example.com to https://www.example.com happens on the web server, not in DNS.

Postgraduate

Changing exact records is the least disruptive way to move a site: it limits blast radius to web traffic and keeps mail, verification and third-party records intact. Plan TTLs ahead of a cut-over so rollback is quick.

Developer

Symbolic example; your real targets come from YPB privately:

example.com.       A      <production address from YPB>
www.example.com.   CNAME  <production target from YPB>
uat.example.com.   A      <UAT address from YPB>
dev.example.com.   A      <DEV address from YPB>

Lower the TTL a day before a change, verify on every authoritative nameserver, then restore the TTL.

Grade school

Moving your whole domain to a new DNS company is a big job. Usually you only need to change one or two web notes instead.

High school

Hostinger offers two ways to connect a domain: change the nameservers, or change the web records. Changing nameservers moves your whole DNS zone and, at Hostinger, sets email records to Hostinger Email — which can break your existing mailbox. YPB recommends changing only the web records.

College

A nameserver change replaces the authoritative zone, so every record must be recreated first — MX, SPF, DKIM, DMARC, verification TXT records. Hostinger notes that its nameservers configure email for Hostinger Email and that you must fix MX if you use another provider.

Postgraduate

Treat a nameserver move as a zone migration with inventory, replication, verification and rollback, scheduled deliberately. It isn’t a routine step in connecting a storefront.

Developer

Export the current zone, recreate it at the destination, diff with dig against both providers, then switch NS at the registrar. Propagation can take up to 48 hours or longer, depending on TTLs (parent-zone NS records are often cached for 48 hours); keep the old zone intact until they expire.