diff --git a/SECURITY/CVE-2019-16378 b/SECURITY/CVE-2019-16378
index a5acd5d..4aaecfa 100644
--- a/SECURITY/CVE-2019-16378
+++ b/SECURITY/CVE-2019-16378
@@ -40,9 +40,9 @@ RFC 7489 also states (Section 3.1.1): Note that a single email can contain
 multiple DKIM signatures, and it is considered to be a DMARC "pass" if any 
 DKIM signature is aligned and verifies.
 
-The behavior of a case of there being multiple distinct domains does not 
-appear to have been considered by this section, as it seems to apply to
-multiple signing agents inside a single administrative domain.
+The behavior in the case of multiple distinct domains does not appear to
+have been considered by this section, as it seems to apply to multiple signing
+agents inside a single administrative domain.
 
 There are additional concerns.  A filter that attempts to perform a full
 DMARC evaluation of every domain found in a multi-valued From could be used
@@ -64,7 +64,7 @@ be processed as normal, so long as there is only one unique domain.
 For all other cases, OpenDMARC has added an option to outright reject messages 
 containing a multi-valued From: field.  If set, messages can be rejected at 
 receipt-time.  If unset, messages will be ignored by the filter.  (They will 
-not pass, but they will not fail).
+not pass, but they will not fail.)
 
-The Authentication-results header field added for the DMARC check in this case
-will have a result of dmarc=permerror.
+The Authentication-Results header field added for the DMARC check in this case
+will have a result of "dmarc=permerror".
diff --git a/SECURITY/CVE-2019-20790 b/SECURITY/CVE-2019-20790
index 351fcca..d93bb14 100644
--- a/SECURITY/CVE-2019-20790
+++ b/SECURITY/CVE-2019-20790
@@ -27,7 +27,7 @@ current SMTP specification) says:
     accept a message on that basis. 
 
 Resolution/Workaround: It is the job of OpenDMARC to trust information 
-provided to it by upstream filters.   OpenDMARC itself can be configured 
+provided to it by upstream filters.  OpenDMARC itself can be configured 
 to validate SPF, but there are use cases where OpenDMARC may be running 
 further inside a network and not have access to the connection strings as 
 logged.  No standard exists for relaying the IP address of the client
diff --git a/SECURITY/CVE-2020-12272 b/SECURITY/CVE-2020-12272
index a3bec9c..195a122 100644
--- a/SECURITY/CVE-2020-12272
+++ b/SECURITY/CVE-2020-12272
@@ -7,8 +7,8 @@ results, as demonstrated by the "example.net(.example.com" substring.
 Link: https://nvd.nist.gov/vuln/detail/CVE-2020-12272
 
 Resolution: OpenDMARC has added checking to validate that the domain
-element in both SPF and DKIM header fields being inspected argument contains 
+element in both SPF and DKIM header fields being inspected contains 
 only valid domain name characters.  This has been fixed as of
-OpenDMARC 1.4.1 (March 2021).  While not mentioned in the CVE, fixes 
+OpenDMARC 1.4.1 (April 2021).  While not mentioned in the CVE, fixes 
 are in a soon-to-be released branch of OpenDKIM as well so that a
 signature bearing such a domain will be considered invalid.