Skip to main content

How to set up SPF, DKIM, and DMARC for white-labeled Juicer accounts

What to add to your DNS so invitation emails reach inboxes instead of spam.

Written by Mario T.

For invitation, confirmation, and password-reset emails sent from your white-labeled Juicer dashboard to reach your users' inboxes (and not their spam folder), you need to authenticate Juicer's email sending against your domain via three DNS records: SPF, DKIM, and DMARC.

This guide walks through the records you'll add at your DNS provider — and what to ask Juicer support to do on our side first, because none of the records below work until we provision a dedicated sending domain for your account in our email provider (Mailgun).

⚠️ Before you start — talk to us first. Pick a dedicated subdomain for transactional email (e.g. mg.yourcompany.com, wlemails.yourcompany.com, mail.yourcompany.com) and contact us with that name. We'll add it as your sending domain in Mailgun and reply with the exact DKIM, SPF, and verification records you need to add at your DNS provider. Until that's done, the records below won't authenticate anything.

A few notes on choosing the subdomain:

  • Don't reuse your white-label feed hostname. If your dashboard lives at, say, socials.yourcompany.com as a CNAME to app.juicer.io, you cannot also host SPF/DKIM/MX records at that same name — DNS doesn't allow other record types to coexist with a CNAME (RFC 1034). A sub-name below the CNAME (like mg.socials.yourcompany.com) often works in practice, but a sibling subdomain at your apex (e.g. mg.yourcompany.com) is the most portable and avoids any chance of resolver inconsistencies.

  • The subdomain becomes the visible "From" address. Your users will see emails arrive from no-reply@<your-sending-subdomain>, so pick something on-brand.

  • Confirm the name isn't already in use. The subdomain should be free of any existing CNAME, A, or MX records at your DNS provider before we provision it.

Step 1: SPF record

SPF tells receiving mail servers that Mailgun is allowed to send mail on behalf of your sending subdomain.

  • Name: <your-sending-subdomain> (e.g. mg.yourcompany.com)

  • Type: TXT

  • Value: v=spf1 include:mailgun.org ~all

Use ~all (softfail) to start. Once everything is verified and you've watched DMARC reports for a couple of weeks with no unexpected failures, you can harden to -all (hardfail) so non-authenticated mail at your sending subdomain is rejected outright.

Step 2: DKIM record

DKIM lets Mailgun cryptographically sign each outgoing message with a key that's published in your DNS, proving the message wasn't forged or tampered with in transit. DKIM is the most important of the three — without it, DMARC alignment cannot pass.

Once we provision your sending domain in Mailgun, we'll send you the DKIM record to add. It looks like this:

  • Name: mx._domainkey.<your-sending-subdomain> (e.g. mx._domainkey.mg.yourcompany.com)

  • Type: TXT

  • Value: k=rsa; p=MIGfMA0GCSqG… (a long public-key string, unique per customer — we send you the exact value)

⚠️ Important: the public-key value is unique to your sending domain and generated by Mailgun when we provision it. Always use the exact value we send you in our reply—paste it as a single unbroken string into your DNS provider's TXT field.

Step 3: DMARC record

DMARC tells receiving servers what to do when SPF or DKIM checks fail, and where to send reports.

  • Name: _dmarc.<your-sending-subdomain> (e.g. _dmarc.mg.yourcompany.com)

  • Type: TXT

  • Value:

v=DMARC1; p=none; pct=100; fo=1; ri=3600; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected],mailto:[email protected];

⚠️ Note on subdomain inheritance: if you already have a DMARC record at your apex domain (e.g. _dmarc.yourcompany.com), subdomains inherit its sp= policy by default. Publish a separate explicit _dmarc.<sending-subdomain> record anyway — it overrides the apex policy and makes the per-subdomain configuration unambiguous.

Verification

After you've added the records and DNS has propagated (usually within an hour, sometimes up to 48), let us know. We'll verify the sending domain in Mailgun and confirm the DKIM signature is valid. You can also test from your side by:

  • Sending a test invite from your dashboard to an inbox you control, then inspecting the message headers—look for spf=pass, dkim=pass, and dmarc=pass all aligned with your sending subdomain.

  • Using a free tool like mail-tester.com: it gives you a unique address to send to and returns a full SPF/DKIM/DMARC report.

Troubleshooting

  • "DMARC fails alignment" in headers: the most common cause is that DKIM hasn't been added correctly, or the records were added at the wrong name (e.g. at the apex instead of the sending subdomain). Double-check the Name field on each record.

  • SPF and DMARC published correctly but mail still goes to spam: if you skipped Step 0 (asking us to provision your sending domain in Mailgun), your records are published on a domain we don't actually sign mail with. Our default sending envelope is on mg.juicer.io so SPF and DKIM authenticate against mg.juicer.io, not your domain, and DMARC alignment against your From: domain fails. There is no DNS-only fix; the Mailgun-side provisioning is the missing piece.

  • Records show up in your DNS UI but receiving servers don't see them: check that there isn't a CNAME at the same name. CNAMEs override every other record type at that name, and the mail records won't be served.

  • DKIM TXT looks split into multiple strings: some DNS UIs auto-wrap long TXT values into 255-character chunks with quotes. That's fine—receivers concatenate them. Just don't manually edit the chunks.

  • SPF "too many DNS lookups" (PermError): SPF allows a maximum of 10 nested include: lookups. If you already have a complex SPF record at your apex and are now adding another for the sending subdomain, you're fine — they're separate records at separate names. The 10-lookup limit applies per record, not across your zone.

  • Hardening SPF to -all: after a couple of weeks of clean DMARC reports, you can switch ~all to -all in your SPF record so non-Mailgun mail claiming to come from your sending subdomain is rejected rather than just flagged. Do this only after you're confident every legitimate sending path is accounted for.

For background reading on what DMARC is and how the records fit together, Cloudflare has a clear write-up at cloudflare.com/learning/dns/dns-records/dns-dmarc-record.

If something doesn't work the way this guide describes, or you're unsure which subdomain to pick, please contact us with the domain you've chosen, and we'll walk through it with you.

Did this answer your question?