Skip to main content
Setting up an email domain verifies the specific subdomain allGood sends and receives replies on. This article covers the layer above that. These are account-wide records that tell every mail provider your domain sends mail honestly. On top of that sits an optional layer that puts your logo in the inbox. None of this is specific to allGood — it’s the same authentication stack behind any marketing email platform, and it’s worth understanding even if you never touch a DNS record yourself.

​
Prerequisites

  • A verified email domain — see Set up an email domain
  • Access to your domain’s DNS settings, or someone on your team who has it
  • Ideally, a way to see your domain’s DMARC reports — see the section below

​
SPF: who’s allowed to send as you

An SPF record is a DNS TXT record on your domain. It lists every mail system allowed to send as you. A receiving server checks the sending server’s address against this list. A mismatch is one of the signals that gets a message flagged or rejected as spam. Whether allGood needs to appear in your domain’s SPF record depends on how your setup is scoped. allGood sends from the dedicated subdomain you registered in Set up an email domain, never your root domain. Because of that, allGood’s own authentication for that subdomain is already handled by the CNAME records you added there. Your root domain’s SPF record only needs to mention allGood if you also send marketing email from an address on your root domain instead. Check with allGood support if you’re unsure which applies to you.

​
The 10-lookup limit

SPF has a hard rule: a receiving server stops after 10 DNS lookups while checking your record. Anything past that limit is ignored, which can mean a legitimate sender silently fails authentication. Every include: in your SPF record counts as at least one lookup. A domain that has added a CRM, a support tool, an e-signature service, and a marketing platform over the years can hit that limit without anyone noticing until deliverability drops. MXToolbox’s SPF Record Lookup tool checks your current record and its lookup count directly. It’s worth running any time you add a new sending tool, not only when something breaks.
If you’re over the limit, the modern recommendation is not to “flatten” your SPF record by converting every include into a raw list of IP addresses. A flattened record goes stale as soon as a provider changes their sending IPs, silently breaking authentication for a service that hasn’t changed anything on its end. A better fix is giving high-volume senders their own subdomain, each with its own lean SPF record — which is exactly what allGood’s dedicated reply subdomain already does for you. If flattening is still the right call for your setup, MXToolbox and similar services offer flattening tools that monitor and auto-update the record, avoiding the staleness problem of a one-time flatten.

​
DKIM: proving a message wasn’t altered

DKIM is the layer covered in Set up an email domain: the two DKIM CNAME records that let allGood cryptographically sign messages sent from your reply subdomain. A receiving server checks that signature to confirm the message came from where it claims, and wasn’t changed in transit. If you need to check a DKIM record’s syntax directly, see DKIMCore’s tools page, also linked from the Web Edge FAQ.

​
DMARC: what to do when SPF or DKIM fails

A DMARC record is a TXT record at _dmarc.yourdomain.com. It tells receiving servers what to do when a message fails SPF or DKIM, and where to send reports about what they’re seeing from your domain. DMARC passes when either SPF or DKIM passes, and is aligned. Alignment means the domain that technically passed the check matches the domain your recipient actually sees in the “From” address. This requirement stops the SPF or DKIM check from being satisfied by some unrelated domain. It’s also usually the reason a setup that looks correct still fails DMARC.

​
Reading reports while you add allGood as a sender

DMARC generates aggregate reports, sent to whatever address your record’s rua= tag names. Each one shows every source that sent mail as your domain, and whether each one passed. The raw reports are XML and not meant to be read directly. A report-monitoring tool — several vendors offer a free tier for smaller volumes — turns them into a readable list of sources. While you’re adding allGood as a new sender, watch your reports for allGood’s sending source specifically. It should show a pass on both SPF or DKIM and alignment. Confirm that for a couple of weeks before tightening your policy.

​
Rolling out your policy

DMARC’s policy tag (p=) has three levels. none monitors only and blocks nothing. quarantine sends failing mail to spam. reject refuses failing mail outright.
Move through these levels gradually. Start at p=none and watch your reports until every legitimate sender — allGood included — shows a consistent pass. Jumping straight to p=reject before confirming that risks silently blocking real marketing email, and possibly other business email you didn’t know was sending from your domain.

​
BIMI: showing your logo in the inbox

BIMI, short for Brand Indicators for Message Identification, displays your logo next to your emails in inboxes that support it. It has two hard requirements before it works at all. Your DMARC policy must be enforced at p=quarantine or p=reject, not p=none. And your logo must be published as a BIMI DNS record in a restricted SVG format called SVG Tiny-PS, capped around 32 KB — not any logo file you already have on hand.

​
VMC and CMC: the certificate BIMI actually needs

Publishing a BIMI record alone isn’t enough for most inboxes to show your logo. You also need a certificate proving you’re authorized to use it. There are two kinds, and the difference matters a lot for a smaller company.
  • A Verified Mark Certificate (VMC) requires a registered trademark on your logo. It costs roughly 650–650–1,700 per year depending on the certificate authority. That’s on top of whatever it costs to register the trademark itself, if you don’t have one already — filing alone runs a few hundred dollars and takes months to process. A VMC is what Apple Mail requires, and it’s what gets you Gmail’s blue verified checkmark.
  • A Common Mark Certificate (CMC) skips the trademark requirement. Twelve months of documented logo use is enough, and it costs somewhat less. Gmail accepts a CMC to display your logo, though without the checkmark. Apple Mail doesn’t accept a CMC at all.
For most small and mid-size companies, a registered trademark is the real barrier, not the certificate fee. A CMC is worth checking into as the realistic path to a BIMI logo in Gmail, without clearing that bar. Yahoo Mail is the exception worth knowing about — it displays a BIMI logo without requiring either certificate.

​
If authentication isn’t behaving as expected

  • A legitimate sender is failing SPF. Check your lookup count first — see the 10-lookup section above.
  • DMARC reports show a pass on SPF or DKIM, but DMARC itself still fails. This is almost always an alignment problem: the passing domain doesn’t match your visible From address.
  • Your BIMI logo isn’t appearing anywhere. Confirm your DMARC policy is actually enforced — quarantine or reject, not none — before checking anything else. BIMI silently does nothing while DMARC is still in monitor-only mode.
If the issue doesn’t resolve, contact allGood support with your domain and which record is in question. Sources: BIMI VMC and CMC certificate guide, dmarcian on ending SPF flattening, MXToolbox on SPF flattening