> ## Documentation Index > Fetch the complete documentation index at: https://docs.brudcast.com/llms.txt > Use this file to discover all available pages before exploring further. # Authentication explained > SPF, DKIM, DMARC and alignment in plain language, how Brudcast sets them up for your domain, and what Gmail and Yahoo require of bulk senders. Anyone can type your address into the From line of an email. Authentication is how a receiving server tells your real mail apart from a forgery. Receivers treat unauthenticated mail with suspicion, and Gmail and Yahoo reject a lot of it outright. There are three standards, and they work together. ## SPF: which servers may send for you **Sender Policy Framework (SPF)** is a list, published in DNS, of the servers allowed to send mail for a domain. The receiver checks whether the server that delivered the message is on that list. The catch: SPF checks the **return-path** domain, the hidden address bounces go back to, not the From address people see. On its own, SPF says nothing about the From line. ## DKIM: a signature on every message **DomainKeys Identified Mail (DKIM)** adds a digital signature to each message. The receiver looks up the matching public key in DNS and checks the signature. If it verifies, the message really was sent with that domain's permission and wasn't changed on the way. The signature names the domain that signed it. That's the domain DMARC compares against. ## DMARC: tying it to the From address **DMARC** is the rule that connects SPF and DKIM to the address people actually see. A message passes DMARC when **at least one** of these is true: * SPF passes **and** the return-path domain matches the From domain, or * DKIM passes **and** the signing domain matches the From domain. That matching is called **alignment**. In the usual "relaxed" mode, subdomains count as a match, so a return path at `brd.spf.mail.example.com` aligns with a From address at `mail.example.com`. Your DMARC record also sets a **policy**: what receivers should do with mail that fails. | Policy | Receivers are asked to | | -------------- | ---------------------------------------------- | | `p=none` | Deliver it as usual, and just send you reports | | `p=quarantine` | Put it in spam | | `p=reject` | Refuse it | ```mermaid theme={"system"} flowchart TD M["Message From: news@example.com"] --> S["SPF: is the server allowed for the return-path domain?"] M --> K["DKIM: does the signature verify, and which domain signed?"] S --> D{"DMARC: does SPF or DKIM pass and align with example.com?"} K --> D D -- "yes" --> P["Pass"] D -- "no" --> F["Apply the policy: none, quarantine or reject"] ``` ## How Brudcast sets this up When you [add a sending domain](/channels/email/add-a-sending-domain), Brudcast generates the records that make your mail pass all three. You publish them once. | Record | What it does for authentication | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | `brd.spf.mail.example.com` (CNAME) | Holds the SPF list for Brudcast's servers. Your bounce address lives under this name, so SPF aligns with your From domain | | `brd1._domainkey` and `brd2._domainkey` (CNAME) | The public keys for the DKIM signature. Brudcast signs with your domain, so DKIM aligns too | | `_dmarc.mail.example.com` (TXT) | A DMARC record with the policy `p=none` | Because both SPF and DKIM align, your mail passes DMARC even if one of them breaks, for example when a forwarding service changes the return path. The details of each record, and why SPF is a CNAME rather than a TXT record, are in [DNS records](/channels/email/dns-records). Once your mail has been passing DMARC for a few weeks, tighten the policy to `p=quarantine` and later `p=reject`. That's what makes your domain hard to forge, and it's a change you make when the DMARC reports show your legitimate mail passing. How the record is published, and what happens if you keep a policy of your own, are in [DNS records](/channels/email/dns-records). The [Brudcast trial address](/channels/email/overview) is authenticated on a domain Brudcast owns. It's fine for getting started, but for real volume, send from your own domain so the reputation you build is yours. ## Gmail and Yahoo bulk-sender rules Since 2024, Gmail and Yahoo have required more of anyone sending a lot of email to their users. Gmail counts you as a bulk sender once you send close to 5,000 or more messages a day to personal Gmail addresses. | Requirement | How you meet it in Brudcast | | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SPF **and** DKIM on your sending domain | Publish the records Brudcast generates, and verify the domain | | A DMARC record, at least `p=none` | Included in the generated records | | The From domain aligns with SPF or DKIM | Both align when you send from your own verified domain | | One-click unsubscribe on marketing mail, honored within 2 days | Campaign email carries a one-click unsubscribe header when unsubscribes are turned on for the domain, and the opt-out takes effect immediately. See [Unsubscribes](/deliverability/bounces-complaints-and-suppression#unsubscribes) | | A spam complaint rate below 0.3% | Up to you. Brudcast warns and then suspends a sending domain at its own levels. See [Reputation and suspension](/deliverability/reputation-and-suspension) | These rules apply even if you're well under the bulk threshold, just less strictly. Meeting them is the simplest way to stay out of spam folders. ## Related The five records and what each one does. Check your records are live. The other half of the bulk-sender rules.