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 fails authentication with no warning. 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, breaking authentication, with no warning, 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.
On your root domain, 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 blocking real marketing email with no warning, and possibly other business email you didn’t know was sending from your domain. Your sending subdomain is different — see the next section.

What allGood requires on your sending subdomain

allGood won’t send marketing email from a domain whose DMARC policy is below quarantine. Gmail and Yahoo require bulk senders to publish DMARC, and a p=none policy asks mailbox providers to deliver mail that fails authentication anyway. The policy that counts is the one in force for your sending subdomain, such as reply.yourcompany.com:
  • If the subdomain has its own record at _dmarc.reply.yourcompany.com, that record decides.
  • Otherwise it inherits from your root domain. If the root record sets sp=, its policy for subdomains, that applies. If not, the root’s p= does.
A root domain still at p=none doesn’t have to hold you up. Publish a record on the sending subdomain alone. It overrides the weaker inherited policy and leaves the rest of your company’s mail untouched. The domain’s card on Email Domains shows the record to publish:
allGood doesn’t create this record for you, and doesn’t collect DMARC reports. Add rua=mailto: with a mailbox of your own if you want them. allGood checks the policy daily, and right away when you click Verify All on Email Domains. While the policy is too weak:
  • The domain’s card says its DMARC policy is too weak for marketing sends, or that it has none, and its DMARC row shows the record to publish.
  • The Email Engine settings page shows Not ready to send, with the DMARC problem in the list.
  • Marketing sends are stopped. Previews to you and your team still go out, so you can keep testing.
A domain whose policy hasn’t been checked yet shows a warning instead of stopping sends. Once the first check finds a weak policy, sends stop. There’s no setting to turn this check into a warning — raising the policy is the fix.

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–$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

  • Sends are stopped with a DMARC message. Your sending subdomain’s policy is below quarantine — often inherited from a root domain still at p=none. Publish the record shown on Email Domains on the subdomain itself. See What allGood requires on your sending subdomain.
  • 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 does nothing, with no error, 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