Email Sending Best Practices: Permission, Branding, and Disclosure

Most senders think of “deliverability” as a technical problem — SPF records, DKIM keys, IP warmup. Those matter, but they are not what gets an account paused. When a mailbox provider or an ESP’s abuse team reviews a sender, they are answering three much simpler questions: did the recipient actually agree to this, does the email look like it comes from who it says it comes from, and does the recipient understand why they’re getting it. Get those three right and the technical side is comparatively easy to fix. Get them wrong and no amount of DNS configuration will save the account.

Only Email People Who Asked For It

This is the one senders get wrong most often, and it’s the one reviewers weigh most heavily. “Permission” does not mean “we found this address somewhere plausible” — a partner’s list, a scraped directory, a conference badge scan, a list bought from a broker. It means the specific person at that address took a specific action to request email from you.

The clearest way to prove this, and the way every major mailbox provider recommends it, is double opt-in: the recipient submits their address, then confirms it by clicking a link in a follow-up email before they’re added to any sending list. Single opt-in (added the moment they submit a form) is faster to grow but carries every typo, every fake signup, and every person who didn’t actually mean to subscribe straight into your active list — and any one of those can turn into a spam complaint.

Two practices matter here beyond the signup form itself:

• Never import a list you didn’t build yourself. A purchased or “aggregated” list has never confirmed consent to hear from you specifically, no matter how well-targeted it looks. This is the single most common root cause of the spam complaints that get accounts suspended.
• Run a permission pass on old lists. If you’re inheriting a list — from a migration, an acquisition, or a CRM that’s been collecting addresses for years — ask everyone on it to confirm they still want to hear from you, and drop everyone who doesn’t respond.

We’ve written a full playbook on the mechanics of this — decay rates, bounce handling, re-engagement sequences — in Email List Hygiene.

Keep Your Branding Consistent

Recipients — and the automated systems that watch on their behalf — expect an email to look like it comes from the same place its content points to. That sounds obvious, but it’s the single most common finding in manual abuse reviews: the sending domain doesn’t match the From name, the From name doesn’t match the logo in the body, or the links in the email go somewhere unrelated to the brand the recipient signed up with.

This gets harder, not easier, if you’re sending email on behalf of more than one brand — an agency, a platform, a reseller. Every identity you send under needs its own consistent chain:

• The sending domain should be the brand’s own domain, authenticated with its own SPF/DKIM/DMARC records — not a shared, generic domain used across unrelated senders. A recipient of “Acme Coffee’s” newsletter should see mail authenticated as coming from Acme’s own domain, not a shared platform domain that also sends for a hundred other unrelated businesses.
• The From name and the content should agree. If the display name says “Acme Coffee”, the logo, the footer, and every link in the body should say the same thing.
• Links should resolve to the brand’s own site, not a generic landing page that doesn’t match what the email describes.

If you’re evaluating a platform to send through, ask specifically how it handles this for multi-tenant sending — whether each customer’s mail authenticates under its own domain, or whether everyone shares one identity. Sharing an identity across unrelated senders means one customer’s bad list becomes every customer’s reputation problem.

Say Why You’re Emailing Them

Every email should tell the recipient, in plain language, why they’re receiving it. This isn’t just good practice — mailbox providers and abuse reviewers explicitly look for it, because its absence is a strong signal that the list wasn’t built on real consent.

A disclaimer line at the bottom of the email, near the unsubscribe link, is enough:

“You are receiving this email because you [signed up for / subscribed to / are a customer of] [Company Name]. If you believe you received this in error or no longer wish to receive these communications, please click the unsubscribe link below.”

Pair it with a working one-click unsubscribe link — never a “reply to unsubscribe” instruction, and never a link that requires logging in first. If you’re building templates in Brixus365, drop a Disclaimer block into the footer of your template; it comes pre-filled with this exact language and the merge tag for your unsubscribe link, so it’s one drag-and-drop away rather than something to remember on every template.

Authenticate Every Sending Domain

SPF, DKIM, and DMARC together prove that an email claiming to be from your domain actually was sent with your authorization. Without them, mailbox providers have no reliable way to tell your mail apart from someone spoofing your domain — and increasingly, unauthenticated mail is filtered or rejected outright before a human ever sees it.

• SPF lists which servers are allowed to send mail for your domain.
• DKIM cryptographically signs your messages so receivers can verify they weren’t altered in transit.
• DMARC tells receivers what to do with mail that fails SPF or DKIM, and gives you visibility into who’s sending mail as your domain.

A domain sitting at p=none in its DMARC record is publishing a policy that does nothing — it reports, but doesn’t protect. Moving to an enforcing policy is one of the highest-leverage things a sender can do, and it’s also one of the first things an abuse reviewer checks. We cover the practical, low-risk path from p=none to a fully enforcing p=reject in DMARC: A Practical Path from p=none to p=reject. For the deliverability fundamentals beyond authentication, see Email Deliverability Guide.

Watch Your Bounce and Complaint Rates

Permission and branding prevent most problems before they start. Monitoring catches the ones that get through anyway — a list that decayed faster than expected, a segment that wasn’t as engaged as it looked, one campaign that went to the wrong audience.

The two numbers that matter, and the thresholds most mailbox providers and ESPs enforce around:

Notice how much stricter the complaint threshold is. A bounce is a dead address — routine, mechanical, expected in small numbers. A complaint is a real person actively telling a mailbox provider your mail is unwanted, and reviewers weigh it accordingly.

If you’re sending at any real volume, don’t wait for a warning email to find out you’ve crossed one of these lines. Set your own internal threshold below the provider’s — half the enforcement line is a reasonable target — so an automated system can pause a problem sender before it becomes an account-wide issue. This matters even more if you’re a platform sending on behalf of multiple customers: isolating each customer’s sending reputation, and auto-pausing the one that’s misbehaving, keeps a single bad actor from dragging down everyone else you send for. We go deeper on reading and recovering from these thresholds in How to Improve Your Sending Reputation, and on the mechanics of bounce handling specifically in Bounce Management.

A Quick Compliance Checklist

1. Every recipient explicitly opted in — no purchased, scraped, or “aggregated” lists.
2. New signups confirm via double opt-in before landing on an active send list.
3. Sending domain, From name, and every link in the email all point back to the same brand the recipient signed up with.
4. Every email includes a plain-language disclaimer explaining why the recipient is receiving it.
5. Every email includes a working, no-login one-click unsubscribe link.
6. SPF, DKIM, and DMARC are all configured and DMARC is moving toward (or already at) an enforcing policy.
7. Bounce and complaint rates are monitored continuously, with an internal threshold set below the provider’s enforcement line.
8. Old or inherited lists get a permission pass before their first send, not after a complaint.

Frequently Asked Questions