The terms you run into when connecting your domain and running your email, explained briefly and without the jargon.
44 terms
An extra address with no mailbox of its own that passes incoming mail to one or more mailboxes.
For example, mail sent to info@company.com can land in the sales@ and jane@ mailboxes. An alias has no password or storage quota of its own. In Mühür Mail, users can also send as an alias that delivers to their own mailbox.
The domain authenticated by SPF or DKIM matching the domain in the message's From address.
DMARC checks not only that authentication passed but that the authenticated domain matches the sender the reader sees. With relaxed alignment (the default) the same organisational domain is enough, for example mail.company.com and company.com; with strict alignment the names must be identical. Mail sent through Mühür Mail has its envelope sender and DKIM signature aligned with the sender's domain.
A separate password used in an email app instead of your account password, issued to that app only.
When two-step verification is on, protocols such as IMAP and SMTP cannot ask for the second step, so you enter an app password in the email app on your phone or computer. If one leaks, you revoke only that password and your account password stays the same. In Mühür Mail, IMAP and SMTP work only with app passwords when the organisation requires two-step verification or an admin turns it on for the mailbox.
A chain of signatures that carries the original authentication results of a forwarded or list message (RFC 8617).
Forwarding can modify a message or change the sending IP, breaking SPF and DKIM. The intermediate server seals the SPF, DKIM and DMARC results it saw on arrival with its own signature; if the final receiver trusts that chain, it can accept the message even when DMARC appears to fail. Mühür Mail adds an ARC seal when forwarding to external addresses and in groups with external members.
An email app finding the server settings by itself from just your email address and password.
Thunderbird queries autoconfig and Outlook queries autodiscover; CNAME and SRV records on your domain point these to Mühür Mail. On Apple devices a configuration profile (.mobileconfig) does the same job. If the records have not been added, the settings are entered by hand.
Bounces that reach an innocent person whose address was forged as the sender of mail they never sent.
When a server first accepts a message and only later finds it cannot deliver it, it sends the bounce to the envelope sender; if that address was forged, the bounce goes to someone who never sent anything. The right behaviour is to reject unknown recipients during the connection. Mühür Mail rejects unknown recipients with 550 during the SMTP session and never generates a bounce afterwards.
A standard that shows the sending organisation's logo in the inbox next to authenticated mail.
The logo is an SVG file referenced by a TXT record at default._bimi.yourdomain.com; most large mailbox providers also require a logo certificate (VMC or CMC). BIMI only works when the DMARC policy is at least p=quarantine. BIMI support is on the Mühür Mail roadmap and is not offered today.
A DNS-queryable list of IP addresses and domains known to send spam.
Receiving servers look up the connecting IP in lists such as Spamhaus and may reject the message or treat it as spam if it is listed. The most common reasons for a listing are spam from compromised accounts and bulk sending to addresses that do not exist. Mühür Mail monitors the listing status of its sending IPs.
A message that could not be delivered to its recipient, and the notice that tells the sender.
A hard bounce is a failure that will not fix itself, such as an address that does not exist; a soft bounce is one that may clear on retry, such as a full mailbox or a temporary server problem. Continuing to send to addresses that hard-bounce damages sender reputation. Mühür Mail retries temporary failures and adds addresses that fail permanently to the suppression list.
A rule that sends all mail for addresses that do not exist on a domain to a chosen mailbox.
It helps you avoid missing mail sent to misspelled addresses, but it also increases spam, because spam sent to random addresses ends up in the mailbox too. In Mühür Mail a domain can have at most one catch-all rule.
A DNS record that points one name to another, like an alias.
When a resolver sees a CNAME it looks up the records of the target name, so when the value at the target changes you do not need to do anything. A name that has a CNAME cannot have any other record, which is why you cannot add a CNAME to the domain itself (@). Mühür Mail uses CNAME records for MTA-STS and automatic configuration, and for DKIM depending on the setup type.
A digital signature added to outgoing mail and verified with a public key the domain publishes in DNS.
The sending server signs the message headers and body with a private key; the receiver uses the selector and domain in the signature to find the public key in DNS and verify it. A valid signature shows that the message was not altered in transit and that the signing domain takes responsibility for it. Mühür Mail signs each domain's mail with that domain's own key.
A name that tells several DKIM keys of the same domain apart.
The public key is published at selector._domainkey.yourdomain.com, and the s= tag in the signature says which selector was used. This lets different services use separate keys and lets an old key stay published for a while during a key change. Without knowing the selector you cannot be sure from DNS alone that a domain has no DKIM key, which is why the domain check tries common selectors. Mühür Mail uses the selectors muhur1 and muhur2.
A policy record that ties SPF and DKIM results to the visible From address and says what to do with mail that fails.
It is a TXT record at _dmarc.yourdomain.com. A message passes when SPF or DKIM passes and the authenticated domain aligns with the domain in the From address. The policy can be p=none (monitor only), p=quarantine (send to spam or quarantine) or p=reject (refuse), and the rua tag gives the address for aggregate reports. Start with p=none and watch the reports, then tighten the policy once every service that sends as your domain is authenticated.
The internet's directory, which turns domain names into IP addresses and email settings.
The records email needs, such as MX, SPF, DKIM and DMARC, live in your domain's DNS zone and are edited in the dashboard of the company you bought the domain from or of your DNS service. Mühür Mail does not register domains; you add the records yourself, or, if you use Cloudflare, Mühür Mail can add them with a token you authorise.
A standard report message telling the sender that a message could not be delivered or is delayed (RFC 3464).
It is what people usually call a bounce message. Next to a human-readable explanation it carries a machine-readable part: the recipient address, a status code (for example 5.1.1, no such address) and the remote server's reply. Codes starting with 4 are temporary failures, codes starting with 5 are permanent.
The sender address given during the SMTP session, to which bounces are returned.
It can differ from the From address the reader sees, and SPF checks the envelope sender's domain. When the message is delivered, this address is written into the Return-Path header. In Mühür Mail the envelope sender is aligned with the sender's domain, so the SPF result also counts for DMARC.
A channel through which a mailbox provider tells the sender when a recipient marks a message as spam.
Feedback loop reports are usually in ARF format (RFC 5965) and identify the message that drew the complaint, so the sender can stop mailing that recipient and find the problem. Senders with rising complaint rates land in spam more often. Mühür Mail processes complaint reports, and a complaining address can be added to the suppression list.
Automatically sending messages that arrive in a mailbox on to another address as well.
When mail is forwarded to an external address the sending server changes, which can break SPF; that is why techniques such as SRS and ARC are used. In Mühür Mail, forwarding to an external address starts working once the destination address is verified.
A spam measure that turns away the first delivery attempt from an unknown sender with a temporary error and waits for a retry.
Real mail servers retry within a few minutes of a temporary error; most spam tools do not. The cost is that the first message from an unknown sender arrives a few minutes late. In Mühür Mail, greylisting is an organisation setting that is off by default.
An address that delivers each incoming message to all of its members.
A message written to a group address such as sales@company.com reaches every member separately, and members can be inside or outside the organisation. In Mühür Mail you choose who can write to a group: anyone, only people in the organisation, or only group members.
The protocol email apps use to read a mailbox on the server and keep folders in sync.
Messages stay on the server, so read status, folders and deletions look the same on every device. If you use the same mailbox on your phone and computer, IMAP is the right choice. Mühür Mail's IMAP server is reached on port 993 with SSL/TLS.
The trust mailbox providers place in a sending IP based on the history of mail from it.
Spam complaints, sending to addresses that do not exist and blocklist listings lower reputation; steady, wanted and authenticated sending protects it. On shared IPs one sender's behaviour affects the others. In Mühür Mail, outgoing mail is scanned and subject to rate limits and a daily quota.
A policy asking senders to deliver mail to your domain only over an encrypted connection with a valid certificate.
When sending servers see the TXT record at _mta-sts.yourdomain.com, they download the policy from mta-sts.yourdomain.com (RFC 8461). The policy lists the valid MX servers and a mode: testing only reports problems, while enforce stops delivery if a secure connection cannot be made. This prevents an attacker from downgrading the connection to plain text. Mühür Mail hosts the policy file for you; all you add are two DNS records.
The DNS record that says which server receives email for a domain.
A sending server looks up the MX records of the recipient's domain and delivers to the server with the lowest priority value, trying the next one if it does not answer. If the MX records are missing or point to the wrong server, mail does not reach you. When you move to Mühür Mail, the MX records are switched to the Mühür Mail servers shown in your dashboard; new mail does not arrive at Mühür Mail until you make that change.
A server that answers authoritatively for a domain's DNS records.
A domain's NS records show where you need to edit its records; if the nameservers point to Cloudflare, for example, the records are added in Cloudflare even if you bought the domain elsewhere. Mühür Mail asks the authoritative nameservers rather than caching resolvers when it checks DNS, so newly added records show up sooner.
A special MX record that states a domain accepts no email at all (RFC 7505).
It is an MX record with priority 0 and a single dot (.) as its target. On domains that do not receive mail it stops senders from retrying in vain and makes messages bounce straight away. While it is in place no mail reaches the domain, so it must be removed when you move to Mühür Mail.
A fake message that poses as a trusted organisation or person to ask for passwords, payment details or money.
Attackers usually use a sender name that resembles a known brand or a company executive, a sense of urgency and a link to a fake sign-in page. Checking the sender address and the real destination of links, and confirming unexpected payment requests through another channel, are the most effective defences. Impersonating a domain whose DMARC policy is p=reject is much harder.
An older protocol for downloading messages from the server to a single device.
In most setups POP3 downloads messages and removes them from the server, and it does not sync folders or read status, so it does not suit people who use one mailbox on several devices. Email apps connect to Mühür Mail over IMAP.
A reverse DNS record that says which server name an IP address belongs to.
Receiving servers check the PTR record of the connecting IP and whether that name resolves back to the same IP; missing or inconsistent reverse DNS can get mail rejected or marked as spam. The PTR record lives in the DNS of whoever owns the IP address (the server or hosting provider), not in your domain. If you use Mühür Mail, reverse DNS for the sending IPs is managed by Mühür Mail and there is nothing for you to add.
Holding suspicious messages in a separate area instead of delivering them to the user.
A quarantined message does not appear in the recipient's mailbox; someone with permission can review it and release or delete it. In Mühür Mail, quarantined messages are kept for the period the organisation sets (30 days by default) and then deleted; messages containing a virus cannot be released.
A sending path that delivers mail through another server instead of directly to the recipient.
Organisations sometimes send through a smart host. A server that relays mail for anyone without authentication is called an open relay; spammers abuse it quickly and it ends up on blocklists. Open relaying is not possible with Mühür Mail; only authenticated users can send, and only as their own addresses.
An open-source spam filter that scores messages against a large set of rules.
Rspamd looks at a message's authentication results, sender reputation, content and links and calculates a spam score. The score is compared against thresholds: the message is delivered, moved to Junk, quarantined or rejected. Mühür Mail uses Rspamd for spam filtering, and organisation admins set the thresholds in the dashboard.
The protocol that carries email between servers and sends it from your email app.
Servers connect to each other on port 25 to deliver mail, while email apps send through authenticated ports 465 or 587. SMTP carries the message but does not verify the sender; SPF, DKIM and DMARC exist to fill that gap.
A TXT record listing the servers allowed to send email on behalf of your domain.
The receiving server reads the record starting with v=spf1 on the envelope sender's domain and checks whether the sending IP is on the list. Ending the record with -all asks receivers to reject everything else, ~all asks them to treat it as suspicious; +all allows anyone and should never be used. A domain should have exactly one SPF record, and mechanisms that need DNS lookups, such as include, must not exceed 10 in total (RFC 7208); beyond that SPF returns an error. Mühür Mail suggests adding its include to your existing SPF record rather than replacing it.
Making a message look as if it came from your domain when someone else sent it.
Because SMTP does not verify the sender address, the From address is easy to forge. SPF, DKIM and an aligned DMARC policy let receiving servers recognise messages that impersonate your domain and reject them with p=reject. Mühür Mail can also show a warning banner on messages from outside the organisation.
Rewriting the envelope sender of a forwarded message to the forwarding domain so that SPF does not break.
Once a message is forwarded, the forwarding server is the one sending it; if the original envelope sender is kept, the receiver's SPF check fails. SRS turns the envelope sender into a signed, time-limited address starting with SRS0=, and bounces still reach the original sender through it. Mühür Mail uses SRS when forwarding to external addresses and for copies sent to external group members.
A command that upgrades an SMTP or IMAP connection that started unencrypted to an encrypted one.
Server-to-server mail on port 25 is encrypted with STARTTLS; email apps send on port 587 with STARTTLS or on port 465 with a connection that is encrypted from the start (SSL/TLS). STARTTLS on its own is not mandatory, so an attacker in the middle can block it; MTA-STS closes that gap. With Mühür Mail, IMAP on 993 and SMTP on 465 are encrypted from the start, and 587 uses STARTTLS.
A list of addresses that failed permanently or must not be mailed, and to which sending is stopped.
Sending again and again to an address that does not exist damages sender reputation. Mühür Mail adds recipients that fail permanently to the suppression list and does not retry them. Organisation admins can add addresses by hand or remove one they know has been fixed.
A record that asks servers sending you mail to report encrypted-connection problems in a daily report.
The v=TLSRPTv1 record at _smtp._tls.yourdomain.com gives the address reports are sent to (RFC 8460). The reports show connections that failed because of MTA-STS or certificate problems, which helps you spot issues before switching MTA-STS to enforce mode.
A value in seconds that sets how long resolvers may cache a DNS answer.
If the TTL is 3600, the old value of a record you change can keep appearing on some servers for up to an hour. Lowering the TTL of your MX records to something like 300 seconds before switching email providers shortens the window in which mail is split between the old and the new provider.
Asking for a second proof at sign-in, such as a code from an authenticator app, in addition to the password.
It keeps an account closed even if its password leaks; compromised accounts are among the most common sources of spam and phishing. In Mühür Mail an organisation can require two-step verification for its whole team, in which case email apps connect with app passwords.
A DNS record that attaches free text to a domain; used for SPF, DKIM, DMARC and ownership verification.
TXT records carry machine-readable settings: SPF starting with v=spf1, a DKIM key starting with v=DKIM1 or a DMARC policy starting with v=DMARC1. Values longer than 255 characters, such as long DKIM keys, are split into several strings; most DNS dashboards do this for you. Mühür Mail verifies domain ownership with a TXT record named _muhur.
Gradually increasing the sending volume of a new sending IP over a number of days.
Mailbox providers are wary of a sudden, large volume from an IP with no history; starting with small, clean volumes and raising them slowly builds reputation. In Mühür Mail, warming up the sending IPs is handled by the platform, so organisations do not need to do anything.
This glossary is general information. The exact format and behaviour of each record is defined in the relevant standards (RFCs); the values for your own domain are shown in the Mühür Mail dashboard.
Check your MX, SPF, DKIM, DMARC, MTA-STS and TLS-RPT records for free and see what to fix.
Check your domainStep-by-step instructions for adding the records at your DNS provider and setting up your email app.
Browse the guidesMühür Mail prepares the records your domain needs, checks each one and tells you what is missing.