SPF, DKIM, and DMARC are not encryption: security boundaries explained

Quick answer for spf dkim dmarc not encryption

Use SPF, DKIM, and DMARC for authentication and alignment when you send as the domain. Do not call them encryption. That is spf dkim dmarc not encryption.

Email authentication and deliverability are receiver policies. Forwarding authentication stays honest when Header From is not rewritten.

Copy sending values from the dashboard on paid send-as. Free has no send-as.

Leftover MX is still a hard stop. Auth records will not fix hop one.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.

Google’s own Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a product is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol.

email authentication: the real decision

Sold DMARC as encryption to a board.

Rewrote From and wondered why DKIM failed.

Ignored leftover MX because SPF was green somewhere.

Criteria: auth vs encrypt named, Header From intact, exclusive MX, no HIPAA claim.

Technical mail flow for spf dkim dmarc not encryption

Inbound: Header From intact. Envelope may SRS. Dest classifies.

Outbound paid: dashboard SPF/DKIM/DMARC values. AUTH SMTP.

A rewrite hop elsewhere still breaks alignment. We do not rewrite From.

TLS is hop security, not at-rest in the dest store.

MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP or POP, not an open relay. Unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Not SOC 2, not ISO 27001, not HIPAA.

deliverability

Write auth versus encrypt on the whiteboard. Then publish records for the path you actually send.

1. Exclusive MX. Named aliases. Inbound probe. Header From intact.
2. If you send as the domain, paid plan. Copy SPF, DKIM, DMARC from the dashboard.
3. Do not add five SPF includes that hit the lookup limit.
4. Do not call a green checker an inbox guarantee.
5. Do not claim encryption or HIPAA.
6. Rotate SMTP if a secret leaked — auth records will not revoke a password.
7. Leftover MX still first if history is empty.
8. Review records after a vendor add.

Failure modes and proof

Encryption theater.

HIPAA from DMARC.

Rewrite-From hop left live.

Green check, leftover MX.

Free send-as 550 ignored.

MailerZ workflow and product boundary

Related: features, security, aliases and catch-all, send and reply.

/security is the questionnaire. Auth TXT is not a badge.

Related pages: features, security, aliases and catch-all, and send and reply.

forwarding authentication

Auth records are DNS. The hop is /pricing. A vault product is another invoice. Do not mash them.

Google helpful-content is for pages. Stay factual.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.

Field notes you can reuse

Loops and leaked aliases are ops. This is vocabulary.

RFC 5321 is transport. DKIM/DMARC have their own RFCs — do not invent ours.

14/90 day hops are not encrypted archives.

SOC 2 is still no.

Agencies: per-zone SPF stories.

Catch-all does not sign mail.

Quarterly leftover plus SPF review.

Workspace native From is their auth story if they own MX.

Deeper field notes for spf dkim dmarc not encryption

Three jobs people mash together

SPF DKIM DMARC not encryption is vocabulary. Authentication: who was allowed to send and whether the message is aligned. Confidentiality: who can read the body. Integrity at rest: a vault. MailerZ does inbound MX and paid SMTP. We do not encrypt Gmail’s store. We do not become HIPAA because a DMARC TXT exists. We do not rewrite Header From. Envelope SRS only. A rewrite hop elsewhere still breaks DKIM/DMARC stories. Delete that hop.

TLS on SMTP is in-transit protection on a hop. It is not at-rest encryption. Dest classify still happens. Green checkers are not Primary. Confirm /pricing. Free has no send-as — no reason to publish a sending SPF include you will not use.

What to publish

Copy dashboard SPF, DKIM, and DMARC when you actually send as the domain. Do not stack includes into the SPF lookup limit. Exclusive MX still first. Leftover Google plus a green SPF story is how boards get lied to.

What to say on a sales call

You may say we authenticate send-as with records we show you, and we do not rewrite Header From on inbound. You may not say encrypted email, HIPAA, SOC 2, or inbox guarantee. Point at /security. Google helpful-content is for pages. Stay factual. RFC 5321 is transport.

Secrets are not TXT records. Rotate SMTP when a human leaves. Auth will not revoke a password sitting in a plugin.

A complete worked story

The board asked if DMARC meant encrypted

A founder said yes. Counsel asked for HIPAA. We said no: MailerZ is not HIPAA, DMARC is not encryption, leftover Google MX was still published. They cut leftovers, kept Header From intact, copied paid send-as records, and bought a real hold product for the matter. Vocabulary was the incident.

Operator brief

A longer operator brief for spf dkim dmarc not encryption

Teams that bookmark SPF, DKIM, and DMARC Are Not Encryption: Security Boundaries Explained usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about spf dkim dmarc not encryption as a send-as, catch-all, or comparison problem.

MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is Mail Box portal webmail, not IMAP, not POP, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.

If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening spf dkim dmarc not encryption. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.

Catch-all forward is not a safety feature for spf dkim and dmarc are not encryption security boundaries explained. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.

Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.

Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear spf dkim dmarc not encryption works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.

Agencies should keep spf dkim dmarc not encryption per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.

Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.

Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.

When SPF, DKIM, and DMARC Are Not Encryption: Security Boundaries Explained is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how spf dkim dmarc not encryption stays a runbook instead of an incident.

A second worked pass for spf dkim dmarc not encryption: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a spf dkim dmarc not encryption mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.

A third worked pass: print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.

Authentication is not confidentiality

SPF, DKIM, and DMARC are not encryption. They authenticate which hosts may send and whether Header From aligns. They do not encrypt the body. A passing DMARC policy does not make the message a vault. TLS on a hop is transport protection for that hop. It is not end-to-end encryption of the store. MailerZ does not rewrite Header From, Subject, Date, Message-ID, body, or MIME. Envelope SRS only. If you need a ciphertext mailbox product, buy that product and cite its docs. Do not hang that claim on this hop.

SPF lists sending hosts. A forwarder that does not use SRS can break SPF at the dest. MailerZ uses SRS on the envelope so the dest SPF check can see a path that is supposed to work. That is still not encryption. DKIM signs headers and body as of the signer. We do not rewrite those fields on inbound, which keeps a signature that was valid at submit from being broken by this layer. A dest that still fails DKIM usually failed before us or failed because another hop rewrote. Print the Authentication-Results at the dest. Do not assume MailerZ stripped the body.

DMARC asks alignment. A privacy-mask From on a provider domain is a different product. A suite mailbox From is a different product. MailerZ send-as uses identities you created. Free cannot finish send-as. Paid plans have hourly send-as ceilings on the pricing page. Those ceilings are not an inbox SLA. They are not HIPAA. MailerZ is not SOC 2 and not ISO 27001. Published security and privacy pages are the wording you can use in a questionnaire.

What a sales call can say without inventing a boundary

You can say: exclusive MX, named aliases, hold unknowns, authenticated SMTP, 550 on unauthorized send, SRS on envelope, no Header From rewrite, 14-day Free store and 90-day paid store for hops this layer saw. You cannot say: we encrypt your Gmail, we are HIPAA, we guarantee Primary, we are SOC 2. If counsel wants eDiscovery, buy eDiscovery. The store windows are recovery, not legal hold.

Cite RFC 5321 for SMTP, RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC when you need a primary source. Cite Google and Microsoft auth docs for dest classify behavior. Commercial competitor pages stay nofollow. Do not invent feature parity with a ciphertext mailbox.

A DMARC pass that still leaked a PDF

An operator enabled a reject policy, saw pass on send-as, and told a customer the thread was “encrypted.” The customer forwarded the PDF to a personal Gmail. The PDF left. DMARC did not stop that. TLS on the hops did not stop a human forward. The honest sentence is: we authenticated the From and we did not rewrite the body. Confidentiality of the attachment after delivery is the dest store and the human.

A second operator thought SPF failure on a forwarded inbound meant MailerZ decrypted something. Nothing was decrypted. Another hop rewrote the envelope without SRS. Public MX was split. Delete the leftover. Probe again. Read Authentication-Results. Name the control.

Related: features, security, aliases and catch-all, send and reply. This page is the boundary. The next action is publish auth records for send-as if you send, and stop calling auth a vault.

What to put on a questionnaire instead of “encrypted email”

Say: SPF, DKIM, and DMARC authenticate sending hosts and alignment. MailerZ does not rewrite Header From or the body on inbound. Envelope rewrite is SRS only. SMTP is authenticated. Unauthorized send is 550 / 550 5.7.1. TLS is used in transit on hops this product speaks. The destination store is Gmail or Outlook unless the customer bought something else.

Do not say: the body is encrypted at rest by MailerZ, we are HIPAA, we are SOC 2, we guarantee Primary, we provide legal hold. The 14-day Free, 90-day Solo–Agency, and 180-day Unlimited windows are recovery for hops this layer stored. Cite RFC 5321, RFC 7208, RFC 6376, and RFC 7489. Cite dest vendor auth docs for classify. Confirm /pricing for send-as ceilings.

If a prospect needs a ciphertext mailbox, they need a different product. If they need a suite, they need a suite. If they need a hop around a mailbox they already trust, this is the hop. Name the control. Stop calling auth a vault. Related: features, security, aliases and catch-all, send and reply.

FAQ

What is the safest way to handle spf dkim dmarc not encryption?

Treat SPF, DKIM, and DMARC as authentication and alignment, not encryption. MailerZ does not rewrite Header From. Copy sending records from the dashboard if you send as the domain. Exclusive MX still matters. Do not claim HIPAA or an inbox SLA from a green checker.

Does this require a new mailbox?

No. MailerZ is Mail Box portal webmail (Inbox, Sent, New email). It is not IMAP or POP. Gmail or Outlook remains the store unless you separately buy a hosted mailbox product.

Will it work with Gmail or Outlook?

Yes for inbound when the destination is a verified mailbox. Branded replies need paid send-as plus Gmail Send mail as or a manual Outlook SMTP identity. Free has no send-as.

What DNS records are involved?

A verification TXT, one MailerZ MX set on the authoritative nameservers, leftover host MX removed, and SPF, DKIM, and DMARC if you also send as the domain.

What should I test before production?

Send a uniquely titled message from an unrelated provider into each named alias. Confirm Header From and delivery history. Do not email yourself from the same Gmail account.

Key takeaways

• Auth ≠ encrypt.
• Header From intact.
• SRS is envelope.
• Green ≠ Primary.
• No HIPAA.
• Exclusive MX still.
• Paid send-as for From.
• Secrets ≠ TXT.

Conclusion and next action

SPF, DKIM, and DMARC are authentication and alignment. They are not encryption. MailerZ keeps Header From intact on inbound. Exclusive MX still decides hop one. Do not sell a TXT record as a vault. Two public resolvers beat one green badge when leftover MX is the real miss.

A green check also does not mean Primary, and it does not mean HIPAA. Destinations still see bodies. TLS on SMTP is transport privacy in transit, not a vault at rest. Point questionnaires at /security. Confirm send-as is Off on Free and On for paid plans on pricing. Leftover MX still splits hop one no matter how green the TXT looks.

Start free. Sign in if a rewrite hop still sits next to MailerZ MX.

Authentication records follow the sender you will use. Mixed leftover includes are not a backup plan.

Review quarterly, or sooner if Gmail, Workspace, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.