Glossary of DMARC and email authentication terms

Each entry below explains one word you meet in DMARC, SPF and DKIM, in your reports, or on our screens. Every entry has its own link, so you can send a colleague straight to the word they asked about.

A to Z: adkim, aspf · Admin · Aggregate report · Alert · Alignment · Authentication · Bounce · Bounce domain · Custom DKIM · Delete everything · DKIM · DMARC · Domain · fo · Forensic report · Forwarding · Guide · History · Mailbox provider · Member · MTA-STS · none · np · Organization · Organizational domain · Passes DMARC, fails DMARC · pct · Plan · Policy · psd · Publish · quarantine · Readiness · Record · reject · Relaxed alignment · Report · Reporting address · Retention · rua · ruf · Selector · Sending service · Sign in · Source · sp · Spam folder · SPF · SPF lookup limit · Spoofing · Strict alignment · Summary · Support · t · TLS report · TTL · Two-step sign-in · Unidentified source · Verify · Viewer

Domain

Your domain is the name after the @ in your email addresses, such as example.com. An admin adds it with Add domain, and everything else belongs to it: its records, its reports and its sources. A subdomain such as news.example.com that turns up in reports is added under its domain by itself. Subdomains need no verification and do not count toward your plan. You can also add a subdomain as a domain of its own, and then it counts. Start monitoring your first domain takes you through adding one.

Record

A record is one entry in your domain's DNS, the public directory other servers read to learn about your domain. SPF, DKIM, DMARC, TLS-RPT and MTA-STS are all TXT records, each at its own name: DMARC lives at _dmarc.example.com. You change records at your DNS host, often the company you registered the domain with. A domain has at most one DMARC record and one SPF record. With two DMARC records, mailbox providers ignore DMARC. With two SPF records, SPF returns an error. The guide What is DMARC? takes a DMARC record apart.

TTL (propagation)

TTL, time to live, is how long other servers may keep a copy of a DNS record before they ask again. Each record has its own, in seconds. After you change a record, a server that holds the old copy goes on using it until the TTL runs out. That wait is what people call propagation. Check now on the DNS tab asks your domain's own name servers, so it sees a change as soon as your DNS host has published it. Scheduled checks may see the old copy for a while. The domain does not verify lists what else to check.

Publish

To publish a record is to add it to your domain's DNS, where every mail server can read it. The Records tab of each domain builds its DMARC and TLS-RPT records with your reporting address in them. If you already have a DMARC record, the new one keeps its tags and adds our address beside any address already there. An admin copies the name and value to the DNS host. If the domain's DNS is at Cloudflare, you can connect Cloudflare instead, and we write the record for you, on every plan. Publish your DMARC record has the steps.

Verify

Verifying a domain proves that it is yours. Either of two TXT records does it: the DMARC record with your reporting address in it, or a verification record at _mailmoni-verify under your domain. Most people publish the DMARC record, because it also starts the reports. We look for both records by ourselves for 7 days after you add the domain, and Check now on the domain's Home tab looks at once. Alerts and scheduled DNS checks start when the domain is verified. Subdomains need no verification of their own. Verify that the domain is yours shows both records.

Authentication

Authentication is how a receiving server checks that a message comes from the domain it claims. Email has three checks for it. SPF checks the server that sent the message. DKIM checks a signature on the message. DMARC checks that SPF or DKIM passed for the domain in the From address, the one people see. When a sending service says your domain is authenticated or verified, it usually means custom DKIM. Authentication says who sent a message. It does not decide whether the message lands in the inbox. The guide SPF, DKIM and DMARC together explains each check.

SPF

SPF, Sender Policy Framework, is a TXT record that lists the servers allowed to send mail for a domain. The receiving server checks the domain of the envelope sender, the return address bounces go to, not the From address people see. So SPF can pass for a sending service's own domain and still do nothing for yours: see bounce domain. Forwarding breaks SPF, because the forwarding server is not on your list. A domain has one SPF record. The guide SPF, DKIM and DMARC together shows where SPF looks.

SPF lookup limit

An SPF check may make at most 10 lookups in DNS. Each include, a, mx, ptr, exists and redirect costs one, and so does every include inside an include. Past the limit, SPF returns an error, and the mail cannot pass DMARC through SPF. Lookups that find no record count as well, against a separate limit of 2 lookups, and past it SPF returns an error too. Each sending service adds an include, so the count grows with every service you add. Our DNS check counts both kinds, shows what each include costs, and warns from 8 lookups or when empty lookups pass their limit. The guide Fix your SPF record shows what to remove.

Bounce domain (envelope sender)

The bounce domain is the domain in the envelope sender, also called the Return-Path or MAIL FROM address. Mail servers send bounces there, and SPF checks it. People reading the message do not usually see it. A sending service usually puts its own domain there, so SPF passes for the service, not for you, and does not count for DMARC. Many services let you use a subdomain of yours instead, such as bounces.example.com. That is a custom bounce domain. The guide Set up DKIM for a sending service shows the step.

DKIM

DKIM, DomainKeys Identified Mail, adds a signature to each message. The signature names a domain in its d= tag and a selector in its s= tag. The receiving server checks it against a public key published in that domain's DNS. A signature survives forwarding, because the message travels on unchanged. A mailing list that adds a footer or changes the subject breaks it. A DKIM key is not a certificate: no authority issues it, and the key record has no expiry date. The guide SPF, DKIM and DMARC together shows where DKIM looks.

Selector

A selector is the name of one DKIM key. The key is published in DNS at selector._domainkey.example.com, so one domain can hold several keys, one per sending service. Each signature names its selector, which tells the receiving server which key to fetch. We learn your selectors from the reports, from the services among your sources, and by trying common names. A selector not seen in a report for 90 days, and with no key in DNS, moves to the retired list, which we still check. The guide Check a DKIM key in DNS helps when a key is missing.

Custom DKIM (authenticated domain)

Custom DKIM means a sending service signs your mail with your domain in the signature's d= tag, not its own. Services call it many things: authenticated domain, verified domain, domain authentication, custom domain. You publish the DNS records the service gives you, usually one or more DKIM keys under your domain. Without it, the signature is the service's, DKIM passes for the service, and it does not count for DMARC. Turning on DKIM in Microsoft 365 or Google Workspace signs only the mail they send, not mail from your other services. The guide Set up DKIM for a sending service has the steps.

DMARC

DMARC, Domain-based Message Authentication, Reporting and Conformance, is one TXT record at _dmarc under your domain. It asks mailbox providers two things. First, what to do with mail that uses your domain in the From address and fails both SPF and DKIM for it: that is the policy. Second, where to send reports about the mail they received in your name: that is rua. The current standard is RFC 9989, which replaced RFC 7489. The guide What is DMARC? explains it from the start.

Alignment

A check is aligned when it passed for the domain in the From address, the one people see. SPF can pass for a sending service's bounce domain, and DKIM can pass for the service's own signing domain. Neither of those counts. DMARC passes when SPF or DKIM passes and is aligned. By default alignment is relaxed: a subdomain of your domain counts too. Where our own calculation and the mailbox provider's result disagree, the provider's result counts, because the provider decided what happened to the mail. The guide SPF, DKIM and DMARC together shows the three domains side by side.

Relaxed alignment

Relaxed alignment, the default, accepts any domain under the same organizational domain. A signature for mail.example.com aligns with a From address at example.com, and so does an envelope sender at bounces.example.com. A DMARC record asks for it with adkim=r for DKIM and aspf=r for SPF, or by leaving those tags out, which means the same. The records we build leave them out, unless your current record spells them out. Relaxed is right unless you know you need strict, because sending services often sign or bounce from a subdomain. The guide SPF, DKIM and DMARC together shows alignment with an example.

Strict alignment

Strict alignment asks for the exact same name. A signature for mail.example.com does not align with a From address at example.com. A DMARC record asks for it with adkim=s for DKIM and aspf=s for SPF. Each tag works alone, so DKIM can be strict while SPF stays relaxed. Mail from a service that signs or bounces from a subdomain then fails DMARC, even though nothing else changed. Our DNS check notes strict alignment as a finding, so a strict tag left in an old record does not go unseen. The guide SPF, DKIM and DMARC together shows how alignment is checked.

Organizational domain

The organizational domain is the part of a name that someone registered: example.com for mail.example.com, and example.co.uk for news.example.co.uk. Relaxed alignment compares organizational domains, so every subdomain of yours aligns with every other. RFC 9989 finds it with a tree walk: it climbs the From domain's name in DNS level by level, and the DMARC records it finds there, psd among them, show where the organization begins. We use the Public Suffix List instead, a list of the endings under which names are registered, such as .fi or .co.uk. For an unusual name our result can differ, and the mailbox provider's own result is what counts in its report. The guide SPF, DKIM and DMARC together has an example.

Passes DMARC, fails DMARC

A message passes DMARC when SPF or DKIM passed for its From domain and is aligned. It fails when neither did. A plain SPF pass or DKIM pass is not enough: the check has to pass for your domain. Only failing mail is affected by your policy. In your reports, a source's pass rate is the share of its messages that passed DMARC. We write "passes DMARC", not "compliant", because DMARC checks one thing about a message. The guide What is DMARC? shows what happens to failing mail.

Forwarding

Forwarding is when a message reaches one mailbox and is passed on to another, by a forwarding rule, an alias or a mailing list. The forwarding server is not on your SPF list, so SPF stops passing for your domain. A DKIM signature usually survives, so forwarded mail still passes DMARC when it is signed with your domain. A mailing list that edits the message breaks DKIM too. Our explanation names forwarded and mailing-list mail as such. When your own services pass, there is usually nothing to fix. The guide SPF, DKIM and DMARC together explains why DKIM survives.

Policy

The policy is the p tag of your DMARC record. It asks mailbox providers what to do with mail that fails DMARC, and has three values: none, quarantine and reject. Mail that passes is not affected by it. The policy is a request: each mailbox provider decides under its own rules. We suggest moving from none to reject in steps, and readiness says when your domain is ready for the next one. The guide The DMARC policy, step by step explains each value.

p=none

p=none asks mailbox providers to handle failing mail as they would without DMARC, and to send you reports. Nothing changes for delivery. It is the first step, because the reports show who sends as you before you block anything. The records we build start at p=none unless your existing record says otherwise. Staying at none for good leaves your domain open to spoofing: someone can still send mail in your name. The guide The DMARC policy, step by step explains when to move on.

p=quarantine

p=quarantine asks mailbox providers to treat failing mail as suspicious. That usually means the spam folder. It is the middle step: mail from a service you forgot about still arrives somewhere, and you can fix that service before you reject. The steps we suggest pass through quarantine twice, first for part of the failing mail with pct, then for all of it. The guide Move to a stricter DMARC policy has the steps.

p=reject

p=reject asks mailbox providers to refuse failing mail while it is being delivered. The sending server usually gets a bounce, and the message never reaches a mailbox. It is the last step and the one that stops spoofing of your domain. A service of yours that still fails loses its mail at reject, so readiness checks your sources first. Forwarded mail that a mailing list changed on the way can be refused too. The guide Move to a stricter DMARC policy has the steps.

sp

The sp tag sets the policy for subdomains of your domain, such as news.example.com. Without it, subdomains follow the p tag. You set sp when subdomains need a different policy, for example sp=reject for subdomains that never send mail while the main domain is still at quarantine. A subdomain with its own DMARC record follows that record instead. Subdomains that appear in your reports have their own pages under their domain. The guide The DMARC policy, step by step covers the policy values.

np

The np tag sets the policy for subdomains that do not exist in DNS at all, such as a made-up invoices.example.com in a From address. Its values are none, quarantine and reject, as for p. Without it, such names follow sp, and without sp they follow p. RFC 9989 added it. A domain still at none for itself can ask for reject on names that cannot send mail anyway. Our DNS check reads np, shows it in the record as written, and flags a value it does not accept. The record builder keeps a valid np as written and leaves out one that is not valid. The guide The DMARC policy, step by step covers the policy values.

pct

The pct tag asks mailbox providers to apply the policy to only part of the failing mail, as a percentage. One of the steps we suggest uses it, so that quarantine starts with part of the mail. It comes from the first DMARC standard, RFC 7489. RFC 9989, which replaced it, lists pct as historic, because providers usually applied it accurately only at 0 and 100. It adds a t tag for testing instead. Our DNS check notes a record whose policy covers only part of the mail. The guide The DMARC policy, step by step explains both tags.

t

The t tag marks a policy as a test. RFC 9989 adds it in place of pct. t=y asks mailbox providers to apply the policy one step lower than written: quarantine is handled as none, and reject as quarantine. t=n, the default, applies the policy as written. Our DNS check reads t and says when a policy is in test mode. Our readiness counts a policy at t=y as the one a mailbox provider that follows RFC 9989 applies, and the record builder has a checkbox for test mode. The guide The DMARC policy, step by step explains both tags.

rua

The rua tag lists the addresses that receive aggregate reports, each as mailto: and an address. Ours is your reporting address. You can keep another service's address beside it, separated by a comma. An address on another domain than yours only receives reports if that domain allows it in DNS. Our DNS check says when it does not. Without rua, mailbox providers have nowhere to send reports and you see nothing. The guide What is DMARC? shows what the reports tell you.

ruf

The ruf tag lists the addresses that receive forensic reports, copies of single failing messages. It is optional, and the records we build leave it out unless you ask for it. Few mailbox providers send forensic reports, and Google and Microsoft do not. A forensic report can contain email addresses and message content, so an admin chooses in the organization settings how we store them. By default we remove personal data and delete the original. The security page says what we remove.

fo

The fo tag says when a mailbox provider should send a forensic report, so it matters only with ruf. fo=0, the default, asks for a report when neither SPF nor DKIM gave an aligned pass. fo=1 asks when either of them did not. fo=d asks when a DKIM signature failed, and fo=s when SPF failed, whether or not they were aligned. Values can be joined with a colon, such as fo=1:d. The record builder on the Records tab offers the four values and leaves out the default. Few providers send forensic reports at all, whatever fo says. The security page says how we store them.

psd

The psd tag, new in RFC 9989, tells mailbox providers where an organization begins when they look for the organizational domain. psd=y marks a public suffix, a name under which other people register their domains, such as a country's registry. psd=n marks the domain as an organizational domain of its own. psd=u, the default, leaves it to the lookup. A company domain does not need it. Our DNS check reads psd and accepts y, n and u. The record builder keeps it as written. The guide SPF, DKIM and DMARC together explains alignment.

Reporting address

Your reporting address is where mailbox providers send your domain's reports, such as k3x9p2m7q4w8@rep.mailmoni.com. Each domain has its own, made of random letters and digits so nobody can guess it. The same address takes aggregate, forensic and TLS reports. It is meant to be public. Anyone can send mail to it, so we treat everything that arrives as untrusted. Mail to an address we do not know is refused during delivery. Our side lets every customer domain send reports to it, so you need no extra record. How it works shows where it fits. What is my reporting address, and is it safe to publish? answers both questions.

Report

A report is a file a mailbox provider or mail server sends to the address in your record, about mail it handled for your domain. There are three kinds. An aggregate report counts your mail and its DMARC results. A forensic report describes one failing message. A TLS report says whether connections to your mail servers could be encrypted. The reports arrive as files attached to email. We read them, show what they mean, and keep the original file of every aggregate and TLS report. The guide What is DMARC? explains what reports show you.

Aggregate report (DMARC report)

An aggregate report, also called a DMARC report or rua report, is an XML file a mailbox provider sends for one period, usually a day. It counts the messages it received in your domain's name, grouped by sending address, with their SPF, DKIM and DMARC results. It holds no message content. These are the report emails people are puzzled to find in their inbox when the rua points at a mailbox. We turn them into sources and sentences, and every report downloads as the file the provider sent. Features shows what we do with them.

Forensic report

A forensic report, also called a failure report or RUF, describes one message that failed DMARC, often with its headers and sometimes its content. Mailbox providers send them only to the addresses in your ruf tag, and few send them at all: Google and Microsoft do not. An admin chooses how we store them: with personal data removed, which is the default, in full, or not at all. With personal data removed, we delete the original message once the report is stored. The security page says what we remove.

TLS report (TLS-RPT)

A TLS report says whether other mail servers could encrypt their connection when delivering mail to your domain, and why not when they failed. Servers that deliver mail to you, mostly large mailbox providers, send one a day as a JSON file. You ask for them with a TLS-RPT record, a TXT record at _smtp._tls under your domain with your reporting address in it. The Records tab builds it. TLS reports are about your incoming mail, so they matter even if you never move past p=none. Features shows what we explain from them. Which reports will I get, and from whom? lists every result type.

MTA-STS

MTA-STS, Mail Transfer Agent Strict Transport Security, lets your domain ask other servers to deliver mail to you only over an encrypted, verified connection. It has two parts: a TXT record at _mta-sts under your domain, and a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. The policy's mode is enforce, testing or none. Our DNS check reads the record and fetches the file. MTA-STS never holds back your readiness. TLS reports show whether servers manage it. What do you check in DNS, and what does a finding mean? has the details.

Mailbox provider

A mailbox provider hosts the mailboxes your mail goes to: Gmail, Outlook.com, Yahoo, or a company's own mail server. It runs the SPF, DKIM and DMARC checks on your mail, applies your policy, and sends you the reports. In the technical views we also call it the reporter, because that is its role in the report file. We avoid "provider" on its own, because your DNS host and your sending services are providers too. The guide What Google, Yahoo and Microsoft ask of senders lists the large providers' rules.

Source

A source is who sends mail as your domain, as we found it in your reports. It is a named sending service, such as Mailchimp or Microsoft 365, or a group of addresses we could not name. We name a source from the service's published SPF ranges, a passing DKIM signature, the addresses' reverse DNS names or their network. Matches from reverse DNS or the network say "probably". Each source gets a sentence that says whether it passes DMARC and what to change. What is a source, and how do you know which service it is? answers both questions.

Sending service

A sending service is a company that sends mail for you as your domain: a newsletter tool, a CRM, a help desk, a webshop or your office mail itself. Each one has to be set up for your domain, usually with DKIM and sometimes with SPF. People also call it an email service provider, or ESP. We recognise many services by name and keep a setup guide for many of them. The services table lists every service we recognise.

Unidentified source

An unidentified source is one we could not name. We group its addresses by reverse DNS name, then by network, and as a last resort show a single address. It may be a service someone in your organization signed up for, a printer, or someone sending mail in your name. An admin can give it a name on its page, and from then on it counts as identified. An unidentified source that never passes DMARC is probably spoofing. The guide Find out who an unknown source is shows what to check.

Spoofing

Spoofing is mail sent by someone else with your domain in the From address. In reports it shows up as an unidentified source whose mail never passes DMARC. At p=none that mail is delivered as before. The quarantine and reject policies stop it, so readiness leaves such sources out: they are the reason to enforce, not a reason to wait. DMARC protects only your exact domain, not look-alike names. The guide Move to a stricter DMARC policy has the steps.

Spam folder (junk)

The spam folder, or junk folder, is where a mailbox provider puts mail it does not trust. "My mail goes to spam" has more than one cause. Failing DMARC under p=quarantine is one. Mailbox providers also weigh other signals, such as how often recipients mark your mail as spam. Passing SPF, DKIM and DMARC tells a provider the mail is really yours, but it does not promise the inbox. The guide What Google, Yahoo and Microsoft ask of senders lists what the largest providers require beyond authentication.

Bounce (rejected mail)

A bounce is the message that comes back when mail could not be delivered. People also say the mail was blocked, rejected, sent back or undeliverable. Under p=reject, a mailbox provider refuses failing mail during delivery, and the sending server returns a bounce to the bounce domain. The bounce quotes the receiving server's reply, a code that starts with 5 for a permanent failure, often with a reason such as a DMARC policy or an authentication level. The guide What Google, Yahoo and Microsoft ask of senders quotes one such error.

Readiness

Readiness is our rule for when a domain can safely move to a stricter policy. By default it reads the last 14 days of reports and needs reports on at least 7 days of them. Every source above a set share of your mail must pass DMARC at a set rate, unidentified sources that sometimes pass must stay below a set share, and the DMARC, SPF and DKIM checks must show no error. Sources that never pass are left out as spoofing. From Pro up you can change the numbers. An alert tells you when a domain becomes ready. When is my domain ready for p=reject? prints the rule in full.

Alert

An alert tells you that something changed: a new source, a drop in the pass rate, a DNS record that changed or broke, a DKIM key that went missing, or reports that stopped. Alerts are for verified domains. Each member gets them by email at a pace set by the plan, at most one alert email a week on Starter and one alert email a day on Pro. Admins start with alert email on, and viewers with it off. Chat channels come with Teams. A problem that cleared before its email went out is not emailed. What will alert me, when, and how often? lists the kinds.

Summary (digest)

A summary is an email with your domains' mail, sources and changes over a period. Each member chooses how often under Settings, Notifications, from the choices the plan allows, or turns it off. Summaries come with Pro, and need at least one verified domain. Some plans can also send summaries to people outside the organization, or to a chat channel. A summary is not an alert: it arrives on schedule whether or not anything happened. What will alert me, when, and how often? explains the other notifications.

History

History is how far back you can see your reports. It depends on the plan: 30 days on Starter, 13 months on Pro, 25 months on Teams and 37 months on Enterprise. Reports older than that are deleted each night. Every page with dates says how much history it shows. When you move to a lower plan, nothing is deleted during a grace period of 14 days. Every aggregate and TLS report downloads as the file the provider sent, as far back as your history goes. We call the same idea retention in legal texts. The pricing page compares the plans. How long do you keep my reports? says what else is kept.

Retention

Retention is how long we keep a kind of data before we delete it. Our legal pages use this word. On the product's screens we say history for reports, because what you want to know there is how far back you can see. Other data has its own retention period, the same on every plan. The privacy policy lists each kind of data, why we hold it, and for how long. The privacy policy has the full list.

Organization

An organization owns your domains, their reports and the plan, and has members. The person who creates it becomes its first admin. Your account is your own sign-in, and one account can belong to several organizations, with a switch between them at the top of the app. An agency, for example, can keep each client in an organization of its own. Deleting an organization deletes its domains and reports. What can a viewer do, and what needs an admin? explains how organizations, members and roles fit together.

Member

A member is a person in an organization, with one of two roles: admin or viewer. The plan sets how many members fit: 1 member on Starter, 3 members on Pro, 15 members on Teams and no limit on Enterprise. An invitation not yet accepted holds a place too. Admins invite and remove members under Settings, Members. Each member chooses their own alerts and summaries. What can a viewer do, and what needs an admin? explains roles.

Admin

An admin is a member who changes things. An admin adds domains, publishes records, invites people, chooses the plan, sets up alerts and channels, names sources, creates API tokens and can delete the organization. Every organization keeps at least one admin: you cannot remove the last one or make them a viewer. There is no separate owner role. Admins start with alert email on. How-to guides cover the admin tasks. Invite members and change roles shows how to make a member an admin.

Viewer

A viewer is a member who reads. A viewer sees every screen, every report and every source, can run a DNS check with Check now, and can download exports. A viewer cannot add domains, change records, settings or the plan, or invite people. New members join as viewers unless the admin who invites them chooses otherwise. Viewers start with alert email off and can turn it on. What can a viewer do, and what needs an admin? compares the two roles.

Plan

A plan sets what your organization can do: how many domains and members, how much history, how often we check DNS, and which features you have. Every organization starts on Starter, which is free, includes 1 domain and does not expire. The paid plans add domains, longer history, more frequent checks, more alerts and more members. No plan limits how many messages your reports may count. The pricing page lists every plan. Which plan has what I need? says where each feature starts.

Sign in

To sign in is to open your account with your email address and your password or passkey. Your account is your own: it holds your email address, your sign-in methods and your memberships. It is not the organization, which holds the domains and the plan. You can add two-step sign-in to make taking over your account harder. Sign in is at the top of every page of the site. The security page says how we protect sign-in.

Two-step sign-in

Two-step sign-in asks for a second proof after your password: a code from an authenticator app on your phone, or a security key. You can also sign in with a passkey. You get recovery codes for when you lose the device. It is on every plan, and you set it up under Settings, Security. Some services call it two-factor authentication or 2FA. It protects your account, and through it every organization you belong to. The security page says what it covers.

Delete everything

Delete everything deletes your organization. It takes effect at once: every member loses access, report mail to its addresses is refused, and its Cloudflare connection and alert channels are deleted. We delete its reports, records and settings within 30 days. A paid plan ends at the same time. Only an admin can do it, under Settings, Data and privacy, and the same page offers to download everything first. The security page says how long we keep data.

Support

Support is where you ask us when something does not work or a page here leaves a question open. Paid plans get an answer within one business day, and Starter as soon as we can. We answer by email, in English or Finnish. Write from the address you sign in with and name the domain, so we can find it. The support page has a form and the address.

Guide

A guide is a page that explains one task or idea, such as how to set up DKIM in a sending service. The public guides are under Learn, and every service we have a guide for is in the services table. In the app, the Playbooks page holds the same setup guides with your own domain and reporting address filled in, and each source links to the one it needs. Learn lists the guides.