DMARC and email authentication are three DNS records with which a company publishes which mail servers may send email in its name, so that other mail servers can reject email faked in its name. DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It works together with two older records, called SPF and DKIM. DNS is the internet's public address book, where each domain can publish short records.
Anyone can type any sender address on an email, in the same way that anyone can write any return address on a postcard. So without these records, an attacker can send an email that appears to come from a bank's own address. Email authentication closes that gap.
SPF, the Sender Policy Framework, is a list of the servers that are allowed to send mail for the domain. DKIM, DomainKeys Identified Mail, adds a digital signature to each email. The receiving server checks the signature with a public key that the company publishes in DNS. DMARC is the rule on top of both. It tells receiving servers what to do with an email that passes neither check for the domain shown in its From address: deliver it anyway (a policy written as p=none), put it in the spam folder (p=quarantine) or reject it (p=reject). It also asks receiving servers to send the company daily reports of every server that sent mail in its name.
Say a cooperative bank in Nashik sends its customers statements and payment alerts by email. It lists its two approved mail services in SPF, and it signs every email with DKIM. For the first month, it sets DMARC to p=none and only reads the reports. The reports show 18,000 emails sent in its name in one week, from servers abroad that the bank has never used. These are phishing emails pretending to be the bank. The bank then changes the rule to p=reject. From then on, a customer's email provider checks every email that claims to come from the bank. Mail from the two approved services is delivered. Mail from any other server is rejected before it reaches the customer.
Why start with p=none? A company often sends mail through services it has forgotten, such as a payroll system or a ticketing tool. If it jumps straight to p=reject, those genuine emails are rejected too. The reports show these services, so the company can add them to SPF first. Tools that read DMARC reports and guide this work are sold on their own, and also together with the secure email gateway. The records themselves are kept in the company's DDI (DNS, DHCP, IPAM) system, which manages its DNS. Large email providers now require companies that send bulk email to publish a DMARC record.
DMARC protects only the company's own domain and its subdomains. An attacker can still register a look-alike domain that differs by one letter, and DMARC cannot stop mail from it. Finding such domains and getting them taken down is the job of digital risk protection.