Email with a seal: SPF, DKIM and DMARC

Result

Your sending domain is green, your DMARC watches, with its reports going to an address that actually receives them or with your plan to get one, and a test email passed SPF, DKIM and DMARC in Gmail.

Estimated time

35 minutes

Cost

US$ 0 to set up. The test email is charged to the wallet like any other, just as in mission 5.

Analogy

Step-by-step guide

Menu paths are shown as they appear in the English interface, with the Spanish name in parentheses for teams that work in Spanish. Google Admin Toolbox, Gmail and your DNS provider are shown with their English labels.

1. 01

   What each part of the seal proves

   In mission 5 you put the seal in place. Today you check what each part proves and whether it works on the receiving end.

   SPF is the list of authorized carriers. Gmail checks whether the server that delivered the letter is on the list published by the envelope's domain.

   DKIM is the wax seal on each letter. Your domain signs, and the receiver uses your public key to check that what was signed didn't change.

   DMARC is your instruction to the post office. It checks that the sender your client sees matches a domain that passed SPF or DKIM.

   DMARC also says what to do with a letter that fails (p=none, quarantine or reject) and where to send the report (rua).

   Key points

   • p=none only watches and asks for nothing. p=quarantine asks to treat failures as suspicious. p=reject says failures aren't yours.
   • DKIM can sign with a domain other than the visible sender's. That gap is the reason DMARC exists.
   • A pass doesn't say the email is good. It says nobody used your domain without permission.
   • DMARC has a new standard: RFC 9989, from May 2026, replaced RFC 7489. The basics hold, but pct was retired, and you'll still see it in older tutorials.
   • What HighLevel requires: every record on your screen, verified. What AXIS recommends: your own DMARC with rua, and the Gmail test.

   Source: F1, F2, F3, F4, F8, F22

   1 · Alba Studio sendsFrom mg.albastudio.com

   2 · The client’s inbox asks three questions

   SPFIs the server that delivered it on mg’s list?

   DKIMIs the wax seal intact, and is it mg’s?

   DMARCDoes the visible sender match a domain that passed? Relaxed: mg.albastudio.com and albastudio.com are the same family

   3 · What it does with failuresp=none: delivers and notes it

   4 · Daily report to the rua

   One aligned PASS is enough. A PASS proves the domain, not the inbox

2. 02

   Your sending domain in green, with your sender on it

   Settings → Email Services → Dedicated Domain And IPCopy path

   In a Spanish-language account: Configuración → Email Services → Dominio e IP dedicados

   If you took path 2 in mission 5, today you create your sending domain with the domain you bought in lesson I.3.1. Do steps 2 to 4 of mission 5 with an mg. subdomain, then come back.

   Inside your sub-account, open Settings → Email Services and choose the Dedicated Domain And IP button. Your subdomain's card is on the Dedicated Domain tab.

   From its ⋯ menu, choose Verify domain. Every record on the list should end up with its green check.

   If one still shows a red ✗, check two things: the name carries only the prefix, and, on Cloudflare, the email.mg CNAME has the gray cloud. Wait 15 to 30 minutes and verify again.

   From the same ⋯ menu, open Set Headers. Enter your business name and an address on your subdomain, like hello@mg.albastudio.com, and save.

   Open the Domain Configuration tab. Each type of email has its own selector: Calendar Domain, Payments, One - One Conversation Domain, Bulk Email Domain, Campaign Domain and Workflow Domain.

   In every selector that says Please Select, choose your sending subdomain and save.

   Take screenshot 1: your records in green, with your sub-account's name in the switcher.

   Key points

   • HighLevel's record guides list five for a sending subdomain. On mg go one SPF TXT and two MX. DKIM goes in a TXT whose name ends in ._domainkey.mg, and the CNAME on email.mg. Another guide says the Verify domain list includes DMARC. If you see a DMARC row, it must be on _dmarc.mg, the same record as in step 3; never add one at your root.
   • Always copy from your screen. The DKIM name and value are unique to your domain, and HighLevel doesn't support two DKIM records for the same domain.
   • Once verified, warmup starts: Stage 1, with a cap of 1,000 emails a day. It moves up a stage only when you send the full daily cap; days passing don't count.
   • One HighLevel guide (June 2026) says warming up a domain generally takes around 4 weeks. The fixed-stage guides make clear it only moves up when you send the full daily cap. If you send 300 emails a day, you stay in Stage 1, and that's fine: the cap leaves you room to spare.
   • Today, going over the cap doesn't block sending, but HighLevel has announced it will enforce it. Don't go over.
   • Set Headers overrides the sender on your campaigns and workflows, but it doesn't touch the reply-to address. HighLevel says the sender should live on your verified domain: that keeps the email DMARC-compliant.
   • If adding a name shows the warning «Domain already pointing to email server», that name already has mail. You only clear MX or SPF from a subdomain you don't use, never your root's.
   • The Risk Assessment tab checks contact lists, not your DNS. No HighLevel article describes a DMARC status inside Email Services: you read your DMARC with Dig.

   Source: F22, F23, F24, F26, F27, F28, F29, F31, F33, F36, F38

3. 03

   Finish your DMARC: watching, with reports

   (your DNS provider) → DNS → TXT _dmarc.mgCopy path

   In a Spanish-language account: (tu proveedor de DNS) → DNS → TXT _dmarc.mg

   Open your domain's DNS zone, wherever your nameservers point (lesson I.3.1). Find the _dmarc.mg TXT record you added in mission 5.

   Edit it; don't add another. If a name has two DMARC records, the receiver throws both away.

   Set this value, with your domain: v=DMARC1; p=none; rua=mailto:dmarc@albastudio.com. It always starts with v=DMARC1.

   The rua is the address that receives the reports. Use one on your own domain that actually receives mail, like a mailbox on your business email.

   If you have no mailbox on your domain, your DNS is on Cloudflare and your root already has a _dmarc, you can try its DMARC Management. Cloudflare adds a rua address of its own to that _dmarc. You can copy it into your _dmarc.mg, but Cloudflare only documents root domains: nothing may arrive.

   Don't use your personal Gmail. A rua outside your domain needs a permission that domain publishes, and gmail.com doesn't publish it for you: the address is ignored. If you have no mailbox on your domain and your DNS isn't on Cloudflare, leave v=DMARC1; p=none; without a rua for now. Take screenshot 2 as is and note in the field which mailbox you'll set up and when.

   The name takes only the prefix, _dmarc.mg. If you type _dmarc.mg.albastudio.com, the provider doubles it.

   If your root already has a _dmarc, don't change its policy: the only addition is Cloudflare's rua, if you choose that route. Your _dmarc.mg governs only mg.

   Save. In 15 to 30 minutes, check it from the outside with Dig (step 4).

   Key points

   • Without rua, nobody sends you reports. Mission 5's p=none was valid, but it was watching blind.
   • Reports come from the providers that received your mail, usually one a day. They arrive as a compressed XML file, with counts per server and SPF and DKIM results, and no personal data.
   • p=none asks for nothing: it only watches. Even with quarantine or reject, the receiver makes the final call.
   • For a rua outside your domain, the receiver looks for a permission in the name of mg.albastudio.com. Cloudflare documents DMARC Management on all its plans, but only for root domains, and doesn't say it grants that permission for mg. If nothing shows after 48 hours, follow «If it breaks».
   • Turning it on adds its rua to your root _dmarc; its docs don't say it changes the policy, but check it in Dig. If your root has no _dmarc, don't accept creating one: use the no-rua route. If someone else set up that record, ask them first.
   • The receiver first looks for the _dmarc of the sender's domain. If there isn't one, it goes up to the root: its sp= applies, or its p= if there's no sp=.
   • That's why your _dmarc.mg matters: if the root had p=reject with no sp=, an mg without its own record would inherit the rejection.
   • If you ever put your sender on the root, the root's _dmarc governs that mail, not mg's.

   Source: F3, F5, F6, F25, F35, F39

4. 04

   Read your zone from the outside

   Google Admin Toolbox → DigCopy path

   Open Google Admin Toolbox and choose Dig. You read what the rest of the internet sees, without signing in to your provider.

   Look up _dmarc.mg.albastudio.com, with your domain, with the TXT type. If you don't see the types, type txt: before the name.

   You should get a single line that starts with v=DMARC1, with p=none and your rua, or no rua if you have nowhere to receive reports yet. That's screenshot 2.

   Look up the TXT for mg.albastudio.com. There should be a single v=spf1: HighLevel's.

   Look up the TXT for albastudio.com and for _dmarc.albastudio.com. Your root is unchanged: your business email's SPF, if any, and its DMARC, if it had one.

   If your root receives email, check it with Check MX: its MX records are still in place.

   If a lookup comes back empty, try the doubled name, like _dmarc.mg.albastudio.com.albastudio.com. If it shows up there, fix the name at your provider.

   Key points

   • A name allows a single SPF. With two v=spf1 records, the check errors out and SPF fails for all your mail. To add a sender, edit the one that exists.
   • SPF has a 10-lookup limit, and every include counts. Going over also errors out. HighLevel's SPF lives on mg, so it doesn't count against your root's.
   • HighLevel's SPF ends in ~all: anything not on the list is «probably not authorized». Don't change it; copy it as it comes.
   • DKIM's public key lives on the name that ends in ._domainkey.mg. It's the mold Gmail uses to check your wax seal.
   • Changes usually show in minutes. Only worry after 24 hours, as HighLevel says. A nameserver change can take up to 48 hours, and Google says up to 72 for a new MX record.

   Source: F16, F17, F18, F1, F21, F23, F35, F40

5. 05

   Send the test and read the seal in Gmail

   Conversations → (test contact's conversation) → EmailCopy path

   In a Spanish-language account: Conversaciones → (conversación del contacto de prueba) → Correo

   Use «Gabby Test» with your code, the contact from mission 10, if her email is a Gmail address. If not, create another test contact with a Gmail address of yours.

   In her conversation, choose the email channel. Make the subject «Seal» plus your code, like «Seal AX-7K2Q», and send.

   Before sending, check the sender: it should be the address on your subdomain, like hello@mg.albastudio.com. If you see another one, change it there.

   In Gmail, on a computer, open the email. Next to Reply, open the ⋮ menu (More) and choose Show original.

   A new page opens. At the top, a table sums up the message: the subject, the sender and one line each for SPF, DKIM and DMARC.

   Look for PASS on all three. The DKIM line names the domain that signed: it should be your sending subdomain.

   Take screenshot 3: that table with your code in the subject and the three passes. Cover your recipient address.

   If DMARC doesn't say PASS, or DKIM names another domain, go to «If it breaks».

   Key points

   • DMARC needs just one aligned pass: SPF's or DKIM's, on the same domain as your sender.
   • Alignment is relaxed by default: mg.albastudio.com and albastudio.com count as the same family. If they were different domains, DMARC would fail.
   • SPF checks the envelope: the technical bounce address, not the sender your client reads. That's why DMARC is needed: it compares against what she sees.
   • Three passes prove nobody used your name without permission. They don't prove the email is good or that it reaches the inbox: that depends on consent, content and your reputation.
   • In Outlook, the result is in the Authentication-Results header: look for spf=pass, dkim=pass and dmarc=pass. In desktop Outlook it's under File → Properties → Internet headers.
   • To read a long header, paste it into Messageheader in Google Admin Toolbox.

   Source: F14, F15, F3, F8, F13, F17, F26

6. 06

   After today: from watching to enforcing, without rushing

   Stay at p=none for at least a month and read your reports. On mg, only HighLevel should send; if you ever add DMARC to your root, you'll also see your website, your invoices and your business email there.

   Move to p=quarantine only when all your legitimate senders pass. Keep it for a similar stretch and compare the reports.

   Only then, p=reject. If people on your domain post to mailing lists, the standard says not to use reject on that domain.

   Don't use pct. DMARC's new standard (RFC 9989, May 2026) retired it. HighLevel's help still suggests pct=25: move up in whole steps.

   Gmail asks every sender for SPF or DKIM and a spam rate below 0.3%. Its goal is under 0.1%.

   From about 5,000 emails a day to Gmail accounts, it also asks for SPF and DKIM, DMARC at least at p=none, alignment and one-click unsubscribe.

   Yahoo asks for the same and gives no number. Outlook.com has required it since May 2025 from anyone sending over 5,000 a day; mail that doesn't comply goes to Junk or gets rejected.

   No record rescues an email nobody asked for. Write only to people who opted in, never to bought lists. HighLevel warns at 3% bounces and suspends sending at 5%.

   Key points

   • HighLevel's DMARC article says Gmail and Yahoo require DKIM and DMARC from everyone. Google asks everyone for SPF or DKIM, and for DMARC from about 5,000 a day. AXIS asks you for DMARC anyway.
   • Why anyway: since November 2025, Gmail rejects more non-compliant mail, temporarily or for good. And the 5,000 count adds up the subdomains of your main domain.
   • Anyone who reaches that number once stays a bulk sender for good.
   • The first two bounce suspensions last 12 hours; the third is permanent and goes through support. Since 13 August 2026, a lock takes at least 500 sends and 25 bounces. Spam complaints count too.
   • One-click unsubscribe is for marketing mail, not transactional mail. Gmail asks you to honor it within 48 hours, and Yahoo within 2 days.
   • HighLevel's help says it automatically adds one-click unsubscribe to the header of every email, except 1:1 emails. Today's test goes out from a conversation, which is 1:1: you won't see it there.
   • Google Postmaster Tools has a compliance dashboard per domain: Compliant, Needs work or No data found. At low volume, No data found is normal.
   • The logo in the inbox (BIMI) isn't for now: it needs DMARC at quarantine or reject and a paid certificate, and the VMC kind requires a registered trademark.

   Source: F3, F25, F7, F8, F9, F10, F11, F12, F19, F20, F30, F32, F37

   Root · albastudio.com · don’t touch

   MX and SPF of the business email

   _dmarc of the root

   Subdomain · mg.albastudio.com

   SPF and two MX on mgFrom HighLevel

   DKIM on …._domainkey.mgFrom HighLevel

   CNAME on email.mgFrom HighLevel

   Your TXT on _dmarc.mgp=none and rua

   From watching to enforcing

   1 · p=none with ruaAt least a month; read reports

   2 · p=quarantineWhen all legitimate senders pass; a similar stretch

   3 · p=reject

   pct=25 · retired in May 2026

   (your DNS provider) → DNS → TXT _dmarc.mg

Interactive

Your email with a seal

This interactive is used inside your AXIS account.

If it breaks

The mistakes that repeat most, and the way out.