Glossary
Email authentication
rua (aggregate reports)
The DMARC tag naming where aggregate reports should be sent. Reports are periodic XML summaries of what receivers saw — counts, sources and results, never message content.
Defined in RFC 7489 §7.2.
Where this appears
The lessons that use this term, and what each is for.
Email Authentication FundamentalsThe policy record, tag by tagRead any DMARC record and state exactly what it asks receivers to do.Email Authentication FundamentalsReading an aggregate reportOpen a raw DMARC aggregate report and explain what a single row means.Email Authentication FundamentalsTelling your senders from everyone elseClassify every source in a report as owned, third-party, or unauthorised, using evidence.SPF PractitionerBuilding the inventoryProduce an evidenced list of every system sending as your domain.DKIM PractitionerWhat to monitorDefine checks that fail before delivery does, not after.DMARC PractitionerEvery tag, including the unused onesWrite a policy record in which every tag is there for a reason you can state.DMARC PractitionerWhat a report does not containState the questions aggregate reports can answer and the ones they never will.DMARC PractitionerSending reports somewhere elseAuthorise an external report destination and confirm reports are arriving.DMARC PractitionerWhere to send themChoose between a processor, a mailbox and both, and say what each costs you.DMARC PractitionerEvidence before policyState the criteria that make the next policy step safe, in numbers from your own reports.DMARC PractitionerFifty domains, one policyRun a consistent policy across an estate without fifty independent records drifting apart.DMARC PractitionerDomains you inheritBring an acquired domain under policy in an order that cannot break its mail.DMARC PractitionerWhat to alert onDefine alerts that fire on the changes that matter and stay quiet the rest of the time.Advanced Email TrustWhat TLS-RPT reportsSay which of your transport problems the reports will show and which they will not.Advanced Email TrustThe bulk-sender requirementsState what the large mailbox providers require of bulk senders, and who counts as one.Advanced Email TrustMonitoring the setDefine the checks that catch each of those failures before a receiver does.Email Security PractitionerWhat it actually costsGive an honest estimate of effort and money for an authentication programme.Email Security PractitionerA spoofing campaignWork an active spoofing campaign in the order that ends it fastest.Email Security PractitionerA worked estateTake a fictional estate from cold audit to enforcement, making every decision explicitly.Email Security PractitionerWhat steady state involvesDefine the recurring work that keeps a finished programme finished.Domain Trust ArchitectureWhat must come firstSequence a programme so each step rests on something already working.Domain Trust ArchitectureHandover that survivesProduce the documentation that lets a successor run the programme without you.Domain Security PractitionerWhat a brief always omitsName the facts nobody writes down that decide most of the plan.Domain Security PractitionerWhat the evidence supportsSeparate what you have established from what you have inferred, in writing.Domain Security PractitionerThe first thirty daysChoose the work that ships in a month with no budget and no dependencies.Domain Security PractitionerOwners and criteriaAssign every item to a party and give each step a condition for proceeding.Domain Security PractitionerThe shape of the reportStructure the document so the highest-value items are the ones acted on.Domain Security PractitionerA year laterDescribe what a successful programme looks like twelve months on, and how you would know.